Built‑in timeout vs manual AbortController for phased axios request timeouts

Goal

I need to enforce separate connect and response timeouts for Axios requests while ensuring that any cleanup logic runs only once per request.

Constraint / Uncertainty

Axios provides a single timeout option that creates an internal AbortController and aborts the request when the limit is exceeded, but it does not expose that controller for custom error handling or phased timeouts. Using the modern signal option with a manually created AbortController lets me set separate timeouts via setTimeout, yet when both timeout and signal are present the internal timeout fires first and may leave the external signal’s abort listener to execute on an already‑aborted request, potentially causing duplicate cleanup. Moreover, the error objects differ (ECONNABORTED vs AbortError) and the abort reason is not automatically propagated.

Open Questions

• Should I rely on the built‑in timeout config and accept its limitations, or implement a manual AbortController with setTimeout to achieve phased timeouts?
• How can I prevent duplicate abort handling when using both timeout and an external signal?
• Is there a way to preserve the abort reason (e.g., “connect” vs “response”) in the Axios error object without wrapping each request manually?