Angular HttpClient interceptor error‑handling pipeline: ambiguous order

Goal

To understand how Angular’s HttpClient interceptor chain processes errors when multiple interceptors are registered.

Context

Angular invokes interceptors sequentially. When an interceptor returns a non‑null response, the chain is short‑circuited for success paths. For errors, the spec does not state a deterministic order among interceptors that handle the same error, leading to inconsistent error‑response transformations.

Constraints

The current implementation may allow any interceptor that throws or returns a failed observable to capture the error, but the order in which they run is undocumented. This uncertainty can cause subtle bugs in logging, retry logic, or user‑facing error messages.

Unresolved Questions

1. What guarantees does Angular provide for the execution order of error interceptors when multiple interceptors throw or transform the same HTTP error?
2. Is there a documented mechanism (e.g., priority, registration order, or explicit configuration) to enforce a specific order of error handling interceptors?
3. How does the retryWhen operator interact with error interceptors in terms of order and potential duplicate requests?