hit UnhandledPromiseRejectionWarning when using this module with `https://github.com/IBM/cloudant-node-sdk`

[SidneyJiang]

I'm working on change cloudant module to https://github.com/IBM/cloudant-node-sdk, and for authentication purpose, I'm using

const { CloudantV1 } = require('@ibm-cloud/cloudant');
const { IamAuthenticator } = require('ibm-cloud-sdk-core');
cloudantDB = CloudantV1.newInstance({
	authenticator: authenticator,
	httpsAgent: keepAliveAgent,
	serviceName: cloudantIamClientId || "pipeline-ui",
	serviceUrl: config.cloudantUrl
});

when I testing my code locally, I hit the following UnhandledPromiseRejectionWarning, do I need to be worried?

[dpopp07]

I think I need a bit more context to understand what is going on. Are you seeing this error when executing just that small snippet above, initializing the client instance? I am guessing not since the error is coming from the formatError function which deals with response errors, so can you share more of the code?

[SidneyJiang]

no, I hit the error when there's a request need to get data from cloudant. Basically when cloudant node module need to talk to cloudant the fetch data. I can't really tell when that happened, but I'm sure it's not during initialization. I spotted that later on when I looking through the logs

[ricellis]

@SidneyJiang do you definitely have a catch at the end of your promise chains?

The not_found here represents a 404 - without more context it's hard to say, but my guess would be that you are missing the catch on the end of a promise chain and hitting a doc ID that doesn't exist, something like:

  await cloudantDB
    .getDocument({ db: 'mydb', docId: 'doesNotExist' })
    .then((res) => {
      // do something with doc
    });

that will result in a UnhandledPromiseRejectionWarning instead of

  await cloudantDB
    .getDocument({ db: 'mydb', docId: 'doesNotExist' })
    .then((res) => {
      // do something with doc
    })
    .catch((err) => {
      // handle doc doesn't exist
    });

when I testing my code locally

A common gotcha people encounter with Cloudant when testing is attemtping to read a document immediately after creating it. Cloudant is eventually consistent - if your read request hits a node where the write has not yet propagated you will get a 404.

[SidneyJiang]

that is not my case. All our cloudant code looks like

		return cloudantDB.getDocument({db: DB_NAME, docId: pipelineId}).then(
			(response) => {
				toCollectData.result = response.result;
			},
			(error) => {
				toCollectData.error = error;
			}
		)

and it is very clear from my original message that the uncaught exception is from ibm-cloud-sdk-core module

[ricellis]

that is not my case

Thanks for showing the code you are using. The Object Not Found and not_found parts of the error are consistent with the 404s produced by CouchDB/Cloudant and not, for example, the IAM authenticator. So I'd still recommend trying to find which request is receiving the 404 as it might indicate the path by which an error can bubble up unhandled.

it is very clear from my original message that the uncaught exception is from ibm-cloud-sdk-core module

I don't think it is very clear. The code sample missing the catch I used reproduces the same UnhandledPromiseRejectionWarning at the core lines 290 & 275:

(node:28631) UnhandledPromiseRejectionWarning: Object Not Found: not_found
    at RequestWrapper.formatError (.../node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:290:21)
    at .../node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:275:45
    at processTicksAndRejections (internal/process/task_queues.js:95:5)

and the stack in the screenshot doesn't reveal which function ultimately made the request that gets rejected.

[SidneyJiang]

I see, I will look through our code again then. Thanks. But it's kinda strange that 404 is not thrown from cloudant module but from ibm-cloud-sdk-core.

[SidneyJiang]

Btw, isn't

(error) => {
	toCollectData.error = error;
}

the catch? I'm kinda sure it does the same thing as catch.. https://dmitripavlutin.com/javascript-promises-then-vs-then-catch/

[padamstx]

I see, I will look through our code again then. Thanks. But it's kinda strange that 404 is not thrown from cloudant module but from ibm-cloud-sdk-core.

Any exception due to an error status code being received from the server (such as a 404) will result in the node core's request processing code throwing the exception as you have experienced. That exception will be thrown by the core and then propagaged up through any generated SDK code (i.e. the code within the cloudant SDK) to your application code that invoked the operation. One way to diagnose this further would be to enable debug logging of requests/responses so you can see the http traffic for each invocation. You should be able to see the 404 response coming back and identify exactly which operation it was. More details about this can be found here: https://github.com/IBM/node-sdk-core#logging

[ricellis]

I'm kinda sure it does the same thing as catch

Yes, I think the then(f, f) pattern should work fine here as well (as long as there aren't additional rejections in the success function) - so it is definitely confusing that one seems to be leaking through unhandled. Hopefully finding the request that gets a 404 will reveal if one is missed somewhere or if there is something else going wrong.

[SidneyJiang]

I think I found what's going on.. There's a call path that doesn't have try/catch on the outmost layer.

I'm ok to close this issue now.. Thanks for the help.