Axios interceptors registration order and CancelToken deprecation in v1.x

Context

Axios v1.x marks CancelToken as deprecated and recommends the standard AbortController API for request cancellation. At the same time, the interceptor chain executes handlers in registration order, meaning later request interceptors can overwrite earlier cancellation logic.

Goal

Determine whether existing interceptors that rely on CancelToken must be reordered or rewritten to work reliably with AbortController.

Constraints and uncertainty

• Default timeout remains 0, so cancellation is the only guard against hanging requests.
• Documentation does not explicitly state how the two cancellation mechanisms interact within the interceptor pipeline.
• Projects may have a mix of legacy and new interceptors registered at different points in the codebase.

Specific questions:

1. Does migrating to AbortController require a defined registration order to preserve cancellation semantics?
2. What is the recommended pattern for replacing CancelToken usage inside request/response interceptors?
3. Are there version-specific behaviors that cause interceptors to be skipped when an AbortSignal is triggered?