Axios validateStatus boundary for 4xx responses and retry eligibility

Goal

Determine whether a custom validateStatus that resolves 4xx responses should also influence retry logic, or if retry decisions must remain decoupled from the resolution boundary.

Constraints and uncertainty

Axios 1.x rejects only 2xx by default; a validateStatus returning true for 4xx makes those responses resolve normally. Downstream code that only handles rejections may then treat client errors as success. The library provides no built-in retry policy, so the application must decide which status codes and network errors are safe to retry. Retrying a 4xx response after it has been resolved risks masking client-side bugs, while retrying a 5xx response on a non-idempotent method can cause duplicate side effects. Network failures without a response produce an AxiosError with request set but response undefined, a shape distinct from HTTP error responses.

Questions

1. Should a retry wrapper inspect error.response?.status even when validateStatus caused the promise to resolve, or is the resolution itself the signal that retry is inappropriate?
2. How do you distinguish between a resolved 4xx that represents an expected business outcome versus one that warrants a retry after corrective action?
3. What criteria should gate retries for network errors lacking a response object when the request method is non-idempotent?