-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I set retry 3 times,but only retry 1 times #68
Comments
Is the axios instance being shared? I ran into a similar issue and found that the retry counter is shared between multiple uses of a single instance. Possibly related to #61 |
Greetings! Can you share a complete code example that does this? We have tests specifically covering number of retries, so an isolated example of how to break it would be super helpful. |
@JustinBeckwith was that WRT my comment? Also, thank you for the awesome tool. I use it in every lambda project. |
Hello @JustinBeckwith, thanks for the library. Here is a reproducible demo for you: https://github.com/tomic-dvica-golf/retry-axios-demo/tree/master just run yarn test. |
Note that #61 was fixed, so this issue is probably also fixed. |
Sweet. Could I trouble anyone to try it and take a look? |
Hi @JustinBeckwith, I ran into the same issue where I have specified both retry count and noResponseRetries to 3. I have debugged the "retry-axios" code and turns out that during the first initial request raxConfig received the correct value of httpMethodsToRetry & statusCodesToRetry i.e Array which I have passed from my code as config. But when an error occurred for first time, The response interceptor is being called with correct raxConfig and in that shouldRetryRequest is called which returns true to retry the 1st attempt of the request. Now, in this 1st attempt of retry, The response interceptor receives the incorrect raxConfig i.e the value of httpMethodsToRetry & statusCodesToRetry is Object this time but not Array therefore when normalizeArray is called from response interceptor it receives Object and return empty Array hence shouldRetryRequest function return false as the condition Please find the attached screenshots for a better understanding. This is the Initial raxConfig when the first-time error occurred which in my case is timeout. Now this is the raxConfig for 1st retry attempt and error occurred, Here you can clearly see the value of httpMethodsToRetry & statusCodesToRetry is Object this time but not Array. now for this error when shouldRetryRequest function called see the config now. therefore Please look into the issue, I'm stuck in some very important project or allow me to debug this furthermore, let see if I can find a cause from where Array is turning into Object |
@JustinBeckwith I have setup a small environment on Repl.it to test it. Here https://repl.it/@seahindeniz/RaxRetryingIssue |
According to the printouts from @morevolk-latei, the keys in the object form are now strings instead of integers. If so, the fix can be pretty simple - just replace
with
|
Here is a full example for timeout error: import axios from 'axios';
import * as rax from 'retry-axios';
const axiosConf = {
timeout: 1000,
raxConfig: {
retry: 3,
noResponseRetries: 3,
httpMethodsToRetry: ['POST'],
onRetryAttempt: (err) => {
const cfg = rax.getConfig(err);
console.log(`Retry attempt #${cfg?.currentRetryAttempt} (after ${err.code} for URL ${err.config?.url})`);
}
}
};
try {
const axiosClient = axios.create();
rax.attach(axiosClient);
const res = await axiosClient.post('http://httpbin.org/delay/2', {}, axiosConf);
console.log(res.data);
} catch (err) {
console.error(err.message);
} Output:
|
Here is a simple example with error code: import axios from 'axios';
import * as rax from 'retry-axios';
try {
const axiosClient = axios.create();
rax.attach(axiosClient);
console.log('Sending request');
const res = await axiosClient.get('http://httpbin.org/status/503', {
raxConfig: {
retry: 3,
noResponseRetries: 3,
onRetryAttempt: (err) => {
const cfg = rax.getConfig(err);
console.log(`Retry attempt #${cfg?.currentRetryAttempt} (after ${err.code} for URL ${err.config?.url})`);
}
}
});
console.log(res.data);
} catch (err) {
console.log(err.message);
} Output:
|
🎉 This issue has been resolved in version 3.1.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
The text was updated successfully, but these errors were encountered: