feat: add disableOtherResponseInterceptors option #260

yutak23 · 2023-12-15T13:07:09Z

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 · 2023-12-15T13:09:05Z

src/index.ts

 import isRetryAllowed from 'is-retry-allowed';

+interface AxiosResponseInterceptorManagerExtended extends AxiosInterceptorManager<AxiosResponse> {


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 · 2023-12-18T00:20:01Z

src/index.ts

+    rejected: ((error: any) => any) | null;
+    synchronous: boolean;
+    runWhen: (config: InternalAxiosRequestConfig) => boolean | null;
+  }>;


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 · 2023-12-21T10:29:28Z

@mindhells, I would appreciate your confirmation.

mindhells · 2023-12-21T12:43:53Z

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 · 2023-12-22T09:34:15Z

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 · 2024-02-13T19:34:39Z

spec/index.spec.ts

+  describe('failure after retry', () => {
+    it('should not multiple response interceptor', (done) => {
+      const client = axios.create();
+      nock('http://example.com').get('/test').times(3).replyWithError(NETWORK_ERROR);


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 · 2024-02-13T20:06:50Z

src/index.ts

+        setTimeout(() => {
+          if (currentState.disableOtherResponseInterceptors && currentState.retryCount === 1) {
+            const responseInterceptors = axiosInstance.interceptors
+              .response as AxiosResponseInterceptorManagerExtended;
+            const interceptors = responseInterceptors.handlers.splice(0, responseInterceptorId + 1);
+
+            // Disable only intercepter on rejected (do not disable fullfilled)
+            responseInterceptors.handlers = interceptors.map((v, index) => {
+              if (index === responseInterceptorId) return v;
+              return { ...v, rejected: null };
+            });
+
+            resolve(axiosInstance(config));
+            return;
+          }
+          resolve(axiosInstance(config));
+        }, delay);


@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 · 2024-02-13T20:29:42Z

@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:

(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.
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 · 2024-02-14T08:33:21Z

@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:

(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.

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.

feat: add disableOtherResponseInterceptors option

75a63ca

yutak23 commented Dec 15, 2023

View reviewed changes

yutak23 added 2 commits December 18, 2023 09:09

test: add testing for patterns of failure after retries

7e7c61e

fix: runWhen should be nullable

e06b2db

yutak23 commented Dec 18, 2023

View reviewed changes

fix: support before and after fullfilled, rejected

8a4c4c1

lavagri reviewed Feb 13, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: add disableOtherResponseInterceptors option #260

feat: add disableOtherResponseInterceptors option #260

yutak23 commented Dec 15, 2023

yutak23 Dec 15, 2023 •

edited

Loading

yutak23 Dec 18, 2023 •

edited

Loading

yutak23 commented Dec 21, 2023

mindhells commented Dec 21, 2023

yutak23 commented Dec 22, 2023 •

edited

Loading

lavagri Feb 13, 2024

lavagri Feb 13, 2024

lavagri commented Feb 13, 2024 •

edited

Loading

mindhells commented Feb 14, 2024

		import isRetryAllowed from 'is-retry-allowed';

		interface AxiosResponseInterceptorManagerExtended extends AxiosInterceptorManager<AxiosResponse> {

	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!');

feat: add disableOtherResponseInterceptors option #260

Are you sure you want to change the base?

feat: add disableOtherResponseInterceptors option #260

Conversation

yutak23 commented Dec 15, 2023

yutak23 Dec 15, 2023 • edited Loading

Choose a reason for hiding this comment

yutak23 Dec 18, 2023 • edited Loading

Choose a reason for hiding this comment

yutak23 commented Dec 21, 2023

mindhells commented Dec 21, 2023

yutak23 commented Dec 22, 2023 • edited Loading

lavagri Feb 13, 2024

Choose a reason for hiding this comment

lavagri Feb 13, 2024

Choose a reason for hiding this comment

lavagri commented Feb 13, 2024 • edited Loading

mindhells commented Feb 14, 2024

yutak23 Dec 15, 2023 •

edited

Loading

yutak23 Dec 18, 2023 •

edited

Loading

yutak23 commented Dec 22, 2023 •

edited

Loading

lavagri commented Feb 13, 2024 •

edited

Loading