Retry failed request using Axios interceptors

In my previous blog post, I discussed interceptors, including Axios interceptors. To continue with this blog post, it’s essential to have a quick read through the previous content or be familiar with the concept of Axios interceptors and how response interceptors function to intercept responses and continue the flow

Manipulating request and response with axios interceptors

Let’s start with the blog now. There may be cases where we need to retry certain requests if they fail or if there’s a need to resend the request.

Some of the popular use cases are:

• Network failures

In cases where a user’s network is slow or disconnected, retrying the failed request could prove beneficial.

• Fallback to backup service

Imagine having two email clients, and if one fails for some reason, it’s prudent to retry the request with the second client. This situation can arise with both external dependencies and internal services.

• Throttled endpoints

Certain endpoints or APIs allow a user to hit them a limited number of times within a specific timeframe. Implementing middleware to retry failed requests after a delay can be advantageous if we encounter throttled errors.

• Rate limiting

Similar to throttled endpoints, there may be instances of rate-limited endpoints where requests are restricted within a certain rate.

Let’s see how we can retry requests on specific errors

In the provided code snippet, an Axios interceptor is implemented. Here’s an explanation of the key points:

1. Line 2: We utilize the axios.create method with the baseURL option to instantiate an Axios instance.
2. Line 8: Axios response interceptors are employed, accepting request and response callbacks. Since we only require the response callback, we specify undefined as the first parameter. The second parameter is a function responsible for handling response.
3. Line 13: We check if the error has a code of `ECONNREFUSED` indicating a timeout or refusal of connection by the service. Additionally, a count is maintained to track the number of retry attempts. If the count exceeds the maximum allowed retries, the request won’t be retried.
4. Line 16: Depending on the current retry count, the base URL is updated accordingly. For instance, if the count is 1, it updates to “PAYMENT_SERVICE_BASE_URL_2”; if it’s 2, it updates to “PAYMENT_SERVICE_BASE_URL_3”.
5. Line 20: The instance with the updated configurations is returned.
6. Line 22: If none of the retry attempts are successful or the maximum retry count is reached, the promise is rejected with the encountered error.

Note: It’s crucial to exercise caution when implementing retry mechanisms to prevent potential infinite loops. Always verify the type of error encountered before attempting a retry. Additionally, consider introducing a delay between retries to mitigate potential issues. If you’re interested, I can provide code for incorporating a delay between retry attempts. Feel free to experiment with the provided guidance and share your findings in the comment section below.

Thanks for reading the blog. If you found it helpful, don’t hesitate to show your appreciation by clicking the clap icon. For any further assistance or questions, feel free to leave a comment below. Your feedback is highly valued!