Robust network error handling strategy

WHAT THIS TESTS Whether you treat network failures as distinct categories with different remedies, and whether you centralize handling instead of scattering try/catch everywhere.

A GOOD ANSWER COVERS Classify failures. A 4xx means the request itself is wrong, so retrying is pointless; handle 401 by refreshing the token, 403 by surfacing a permissions message, 404 by an empty state, and 422 by field-level validation feedback. A 5xx is typically transient, so retry with exponential backoff plus jitter, capped at a few attempts, ideally only for idempotent requests. A connectivity failure, detectable with NetInfo, should not be confused with a server error; queue the action or show an offline banner and retry on reconnect. Centralize all of this in an Axios response interceptor or a fetch wrapper so every call benefits, log errors to a service like Sentry, and present human-readable messages.

COMMON WRONG ANSWERS A single generic catch that retries every error including 400s, retrying non-idempotent POSTs blindly, showing raw error objects, or treating a timeout identically to a 500. Ignoring token-refresh flows for 401 is a frequent gap.

LIKELY FOLLOW-UPS Why add jitter to backoff? Which methods are safe to retry automatically? How do you avoid an infinite refresh loop on repeated 401s? How does a circuit breaker fit?

ONE CONCRETE EXAMPLE A response interceptor inspects the error: on 401 it attempts a single token refresh and replays the request; on 503 it retries after delays of roughly 1s, 2s, and 4s with random jitter, then gives up and surfaces 'Service unavailable, try again'; on a network error from NetInfo being offline it queues the mutation and shows an offline banner, replaying when connectivity returns. A 400 is never retried; the validation message is shown immediately.