Repository navigation
fix(axios): stop the 401 refresh-retry loop with a once-only guard - #414
Merged
Merged
Conversation
The response interceptor treated every 401 as an expired session: it refreshed the token and replayed the original request. When a refresh succeeded but the replay still returned 401 (an authorization failure, not an expired token), the request looped forever at ~5 req/s — a self-inflicted request storm that drove a production error spike. The `_retry` flag was logged but never set or checked, so nothing broke the loop. Set it at all three post-refresh replay sites and add a once-only guard: a second 401 after a successful refresh means the refreshed token is being rejected, i.e. the session is broken — not something to retry. Clear auth and route to re-login for authenticated requests (matching the existing refresh-failure handling), which also prevents sibling requests from storming.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The response interceptor treats every 401 as an expired session: it refreshes
the token and replays the original request. When a refresh succeeds but the
replay still returns 401 (an authorization failure, not an expired token), the
request loops forever at ~5 req/s — a self-inflicted request storm that drove a
production error spike. The
_retryflag was logged but never set or checked,so nothing broke the loop.
Fix
_retry = trueat all three post-refresh replay sites.refreshed token is being rejected — the session is broken, not something to
retry. Clear auth and route to re-login for authenticated requests (matching
the existing refresh-failure handling), which also prevents sibling requests
from storming.
Verified there are exactly three replay sites (all now guarded) and that the
failedQueuepath is vestigial (nothing enqueues), so there is no unguardedreplay.
Companion
The root cause is also fixed server-side in
openmeet-api(branchfix/event-series-non-owner-403), which returns 403 instead of 401 for theownership failure that triggered this. This guard is defense-in-depth for any
endpoint that legitimately 401s after a successful refresh.