AbortController transition and request interceptor lifecycle in Axios v1.x

Short Answer

In Axios v1.x the request interceptor chain always runs to completion before the HTTP call is dispatched, even if an AbortSignal fires during that chain. Axios does not automatically cancel any asynchronous work started inside an interceptor; you must check the signal yourself. If the signal is already aborted when the chain finishes, Axios aborts the underlying network request, but any pending promises or timers started by interceptors will keep running and can leak memory.

Detailed Explanation

Axios executes request interceptors sequentially:

1. Each interceptor receives the config object.
2. If it returns a value (or a promise that resolves to a value), that value becomes the new config for the next interceptor.
3. After the last interceptor resolves, Axios checks the AbortSignal on the config. If signal.aborted is true, the request is aborted and the promise rejects with AxiosError: Request aborted.
4. Only then does Axios dispatch the actual network call.

Because the abort check happens *after* the interceptor chain, a signal fired during interceptor execution does not interrupt the chain. All interceptors run to completion, regardless of the abort state.

Implications for Async Interceptors

When an interceptor performs asynchronous work (e.g., a setTimeout, a fetch to a token endpoint, or any promise that never resolves), Axios has no built‑in mechanism to cancel that work if the request is aborted mid‑chain. The promise will still resolve or reject, and any side effects will occur. If the async task allocates resources or registers callbacks, those resources may remain until the task completes, leading to memory or resource leaks.

Mitigation Strategies

• Explicit abort checks: Inside any async interceptor, periodically check signal.aborted and reject early if true.

  async function authInterceptor(config) {
    const { signal } = config;
    if (signal.aborted) return Promise.reject(new axios.Cancel('Aborted before auth'));
    const token = await fetchToken(signal); // token fetch should also respect abort
    config.headers['Authorization'] = `Bearer ${token}`;
    return config;
  }
  

• Abortable utilities: Use helper libraries (e.g., axios-extensions) that wrap async work with AbortSignal support.
• Cleanup timers: If you start a setTimeout or setInterval inside an interceptor, store the ID and clear it when the signal fires.

  let timer;
  function interceptor(config) {
    timer = setTimeout(() => {/* long‑running logic */}, 2000);
    config.signal?.addEventListener('abort', () => clearTimeout(timer));
    return config;
  }
  

• Avoid long‑running tasks in interceptors: Prefer synchronous or short‑lived async operations. Heavy work should be delegated to separate services or queued after the request completes.

Testing the Behavior

Below is a minimal test that demonstrates the points above:

const axios = require('axios');
const instance = axios.create();

// Interceptor that logs and returns immediately
instance.interceptors.request.use(config => {
  console.log('Interceptor 1');
  return config;
});

// Async interceptor that resolves after 100 ms
instance.interceptors.request.use(async config => {
  console.log('Interceptor 2 start');
  await new Promise(r => setTimeout(r, 100));
  console.log('Interceptor 2 end');
  return config;
});

const controller = new AbortController();
setTimeout(() => controller.abort(), 10); // abort before interceptors finish

instance.get('https://jsonplaceholder.typicode.com/todos/1', {
  signal: controller.signal
}).catch(err => console.log('Request error:', err.message));

Output:

Interceptor 1
Interceptor 2 start
Interceptor 2 end
Request error: Request aborted

Both interceptors ran to completion before the request was rejected. If the async interceptor had started a longer setTimeout that never checked signal.aborted, that timer would still fire after the request was aborted, illustrating a potential leak.

What You Should Ask Yourself

To give you a more tailored recommendation, I need to know:

• Are you running Axios in a browser environment or in Node.js?
• Do any of your interceptors perform long‑running async work (e.g., token refresh, file uploads, custom timers)?

These details determine the best abort‑handling pattern for your setup.