feat: add disableOtherResponseInterceptors option

[yutak23]

This ought to fix #246.

As commented in the following issue, axios-retry calls a new axios in the response interceptor, so if it succeeds after a retry, for example, the following console.log will be executed many times.
#246 (comment)

axios.interceptors.response.use(
	(response) => {
		console.log('Response Interceptor');
		return response;
	},
	null
);

The proposal is to set the disableOtherResponseInterceptors option to true so that the only response interceptor for axios during the retry process is the one set in axios-retry, so if the retry is successful, the response interceptor set in axios for the first request is executed only once.

[yutak23]

There is a handlers property in the axios request/response interceptor, but it is not present in the current axios type definition. Therefore, we are extending it on our own.

However, if the following PRs are merged, this definition will no longer be necessary.
axios/axios#6138

But, it is not clear when the proposal will be adopted, so the axios-retry side would be quicker to merge first with this definition.

[yutak23]

I have checked the following JavaScrip implementation on my end and defined the types.
https://github.com/axios/axios/blob/v1.6.2/lib/core/InterceptorManager.js#L23

[yutak23]

@mindhells, I would appreciate your confirmation.

[mindhells]

I'm sorry @yutak23 I've been very busy lately.
I'm not really sure this should be part of the responsibility of this library 🤔
Can you guarantee other interceptors are not executed at that point, regardless of the order they have been registered?

[yutak23]

I'm sorry @yutak23 I've been very busy lately. I'm not really sure this should be part of the responsibility of this library 🤔 Can you guarantee other interceptors are not executed at that point, regardless of the order they have been registered?

@mindhells , I apologize for rushing you.
Yes, i implemented it so that the intended movement is independent of the order in which the interceptors are registered.
I have enhanced the test cases in the latest commit.

[lavagri]

Suggested change

	nock('http://example.com').get('/test').times(3).replyWithError(NETWORK_ERROR);
	nock('http://example.com').get('/test').times(3).replyWithError(NETWORK_ERROR);
	nock('http://example.com').get('/test').reply(200, 'It worked!');

I assumed that adding this line here wouldn't affect test results, but it did. Am I mistaken? :)

[lavagri]

@yutak23 Thanks for your input!

I tested your solution under all test cases we have at the moment I created issue #246 – all passed 🎉

Unfortunately, we have received more production cases and updated our patch. Our previous version was not working properly with API client contest requests. Your solution appears to make the same mistake by detaching interceptors from the global client.

Here is seq diagram, to represent this simple contest use-case

The main change we made was to clone (dirty) the Axios client, so the global detachment of handlers won't affect contest requests through the same client.

Our new patch looks like this:

diff --git a/node_modules/axios-retry/lib/cjs/index.js b/node_modules/axios-retry/lib/cjs/index.js
index 1cfaeed..3dbc698 100644
--- a/node_modules/axios-retry/lib/cjs/index.js
+++ b/node_modules/axios-retry/lib/cjs/index.js
@@ -335,10 +335,17 @@ function axiosRetry(axios, defaultOptions) {
               config.transformRequest = [function (data) {
                 return data;
               }];
+
               onRetry(currentState.retryCount, error, config);
               return _context.abrupt("return", new Promise(function (resolve) {
                 return setTimeout(function () {
-                  return resolve(axios(config));
+                  var newClient = axios.create();
+
+                  var retryInterceptors = axios.interceptors.response.handlers[responseInterceptorId];
+
+                  newClient.interceptors.response = [retryInterceptors];
+
+                  return resolve(newClient(config));
                 }, delay);
               }));
 

We don't use custom interceptors before axios-retry so far, so your solution is more solid, and still looks better.
But could you confirm that your solution overcome this issue by providing new test cases?

[lavagri]

@mindhells I apologize for creating any confusion, maybe my previous explanations in the issue were too abstract. I still think that axios-retry should handle this. Let me try to convince you with a more concrete example.

TikTok Marketing API returns 200 mainly for all responses, wrapping everything in this structure

{ 
    code: 40002, // everything that not "0" = "error"; in this example it's kind of 400, but statusCode still 200 
    ...,
    data: {...} // present in all "success" (code: "0") and sometimes in "error" responses
}

I want to achieve 2 things and still use axios-retry library:

1. (optional, maybe out of this PR, but still 🙂) attach my interceptors before axios-retry and map code to specific error, throw it, catch it in retryCondition(), and retry if it's needed.
2. attach my interceptor after axios-retry: return axiosResponse.data.data (if code = "0" = success). But the current implementation will call my interceptors N times, which eventually leads to "Cannot read properties of undefined" errors: you can't read axiosResponse.data.data.data (* N times accessing .data, where N = retry times)

I expect that If axios-retry lib strategy is to add +1 interceptor to the original axios client, it will execute only that interceptor on retries w/o touching my pre/post interceptors.

[mindhells]

@mindhells I apologize for creating any confusion, maybe my previous explanations in the issue were too abstract. I still think that axios-retry should handle this. Let me try to convince you with a more concrete example.

TikTok Marketing API returns 200 mainly for all responses, wrapping everything in this structure

{ 
    code: 40002, // everything that not "0" = "error"; in this example it's kind of 400, but statusCode still 200 
    ...,
    data: {...} // present in all "success" (code: "0") and sometimes in "error" responses
}

I want to achieve 2 things and still use axios-retry library:

1. (optional, maybe out of this PR, but still 🙂) attach my interceptors before axios-retry and map code to specific error, throw it, catch it in retryCondition(), and retry if it's needed.
2. attach my interceptor after axios-retry: return axiosResponse.data.data (if code = "0" = success). But the current implementation will call my interceptors N times, which eventually leads to "Cannot read properties of undefined" errors: you can't read axiosResponse.data.data.data (* N times accessing .data, where N = retry times)

I expect that If axios-retry lib strategy is to add +1 interceptor to the original axios client, it will execute only that interceptor on retries w/o touching my pre/post interceptors.

Hi @lavagri,
thanks a lot for trying to give more detail on the motivations for this PR.
I quite not get your 2nd point 😅, what it's what makes the response to have a nested structure (.data.data.data)?

On the other hand, my concerns with having this implementation are:

• it's complex and rigid (you cannot decide which other interceptors should be disabled, maybe you don't want all).
• (not sure about this one) you could do the same leveraging the onRetry callback, and you'd have the ability to decide which specific interceptors you want to disable.
• we are relying on undocumented properties (I know we are already doing for other things).

But, given the feedback I'm seeing in #246, let's do the following: if axios/axios#6138 gets merged and @yutak23 confirms the use cases you are mentioning are covered, we'll merge this.