Support for retry mechanism in SDK

[saristar]

Is your feature request related to a problem? Please describe.
My current project was using nodejs-cloudant library and since it is deprecated I'm shifting to IBM cloudant-node-sdk. I was using some of the plugins from the library and one of it is retry. Currently I do not see any retry mechanism in the new SDK.

Describe the solution you'd like
Like in previous library where there was support for retry mechanism using a plugin, it would be better if we have similar retry mechanism in this SDK.

[ricellis]

This feature is going to be provided from the node-sdk-core to reach parity with the other SDKs.

If you need the feature immediately you can temporarily workaround the limitation by using an axios retry plugin e.g. axios-retry or retry-axios and applying it directly to the SDK's underlying axios instance e.g. where client is your CloudantV1 instance:

const rax = require('retry-axios');
client.getHttpClient().defaults.raxConfig = {
    // ... retry-axios config options
    instance: client.getHttpClient(),
  };
rax.attach(client.getHttpClient());

or

const axiosRetry = require('axios-retry');
axiosRetry(client.getHttpClient(), {
    // ... axios-retry config options
  },
});

Note: snippets updated to use official getHttpClient() method

[pheuberger]

Any alternatives for TypeScript users as this one fails, because TS doesn't allow me to access a private member of BaseService?

[ricellis]

Same as #408 (comment) from the next release TS users will be able to get the axios instance to do a workaround until the core provides built-in retries.

[pheuberger]

Ah, brilliant! When is this going to be released?

[ricellis]

Hopefully no later than the end of the month.

[pheuberger]

Nice, looking forward to it :)

[ricellis]

0.0.18 released today with support for

client.getHttpClient()

to access the axios instance (even in TS).

To be clear enabling retries via user-supplied plugins to axios is still a workaround. I'm leaving this open until we have the built-in retry support (which is hopefully coming soon in the core, see IBM/node-sdk-core#156).

[pheuberger]

Thank you @ricellis! For now this will do.

[ricellis]

I'm going to close this as we've picked up the new 2.14.0 core via #447. So we will have the built-in retry capability from the next 0.0.19 release.

[kvv002]

Hi @ricellis , when will 0.0.19 be released?

[ricellis]

Hopefully sometime in the next week.

[kvv002]

Hi @ricellis , Does this release include retry options other than maxRetries, maxRetryInterval, I wanted a parameter which could support retryStatusCodes, I have tried the same parameter which is supported by axios but it doesnt seem to work with enableRetries(), below is my sample snippet

service.enableRetries({ maxRetries: 2, maxRetryInterval: 100, statusCodesToRetry: [404] });

[ricellis]

@kvv002 The node-sdk-core uses retry-axios defaults of statusCodesToRetry: [[100, 199], [429, 429], [500, 599]].

If you'd like to see an enhancement to the core to support configuration of alternative codes you can raise an issue there for discussion. Alternatively you can use the workaround above to configure custom retries instead of using the built-in support.

FWIW I can't think of anywhere in the API where it makes sense to retry a 404 - if your app is relying on that pattern I think a review might identify a more optimal design.

[kvv002]

@ricellis , that was just an example, let me change it to another one like service.enableRetries({ maxRetries: 2, maxRetryInterval: 100, statusCodesToRetry: ['ENOTFOUND'] })]