[Due for payment 2026-08-07] Session not re-authenticated after short-lived token transition from OldDot to New Expensify — user stuck loading with repeated 407s

[melvin-bot]

Problem

After a user transitions from OldDot (Classic) to New Expensify via a short-lived token (the /transition?...&shortLivedAuthToken=... flow), the resulting session is not re-authenticated when its authToken later expires. Instead of transparently re-authenticating, the app fires a continuous stream of 407 responses (expired/invalid authToken) and the user is left stuck on an endless loading state (observed on the Reports page and Inbox).

This is not SAML/SSO related and does not involve Copilot — it's a plain short-lived-token transition session.

What happens

1. User transitions from OldDot to New Expensify via a short-lived auth token (/transition?...&shortLivedAuthToken=...). This initial load works.
2. User closes the app and re-opens it later.
3. The authToken has expired. Every subsequent request returns 407.
4. The Reauthentication middleware does not successfully re-authenticate, so the 407s repeat indefinitely and the UI never finishes loading.

Expected

When the authToken expires, the Reauthentication middleware should transparently obtain a fresh authToken and recover, rather than looping on 407s and leaving the user stuck loading.

Notes / evidence

• Reproduced from a real account (transition began the prior day, 407s started when the app was re-opened later). Internal FullStory session and VictoriaLogs showing the 407 flood are available on request.
• Related but distinct: [Due for payment 2026-07-21] [$500] [Mobile] Okta SSO requires double login after idle timeout — app freezes on SAML session handoff #86705 (SAML idle-timeout double login), [$250] Severe Auth Issues on Mobile: Login Failures, Frequent Logouts, and Inability to Log Out #89613 (mobile auth logouts), [Due for payment 2026-07-23] Copilot: old design (Classic/OldDot) screens shown & stuck loading when copilot account's authToken expires #94329 (copilot authToken expiry). This issue is specifically the short-lived-token transition path with no SAML and no Copilot.

Platform

Web (New Expensify)

Reported in Slack.

Issue Owner

Current Issue Owner: @eVoloshchak

[VickyStash]

Here are some findings from me, I wasn't able to repro the issue in a natural way, only by mocking Onyx data as mentioned below.
But with mocked steps I ended up exactly at state where I have endless loading/all requests failing with 407 but I'm not logged out.

Root cause (confirmed end-to-end from production logs)

A deadlock triggered when a client that is behind on Onyx updates re-enters via /transition. The failure is purely client-side (the fresh token never gets applied):

1. Stale client update pointer → sign-in response deferred. The client's OnyxUpdatesLastUpdateIDAppliedToClient is behind the SignInWithShortLivedAuthToken response's previousUpdateID. OnyxUpdateManager detects a gap, so it does not apply the response inline — it buffers it to onyxUpdatesFromServer and waits for a gap-fill.

   [App] lastUpdateIDFromClient is less than the previousUpdateID received, client needs updating
   [Onyx] set called for key: onyxUpdatesFromServer ... hasChanged: true
   

   The buffered response carries the new authToken + durable logins credential — but it is never applied (no session merge follows the 200), and the gap-fill fetch never fires.

2. Delivery channels also require the expired session token. The durable credential is additionally pushed via Pusher on the user's private-encrypted channel + a SendFetchableOnyxUpdates fallback. Both need auth; AuthenticatePusher 407s (the client is still on its expired session token), so the client never receives it that way either.

3. Reauth aborts instead of recovering or redirecting. Because the session is marked short-lived-in-progress (signedInWithShortLivedAuthToken) and account.isLoading !== false, reauthenticate() takes the abort branch (src/libs/Reauthentication.ts:179-190) and returns false without redirecting:

   [hmmm] [Reauthenticate] Authentication with shortLivedToken is in progress. Re-authentication aborted.
      isSupportAuthTokenUsed: ''   accountIsLoading: 1
   

   This line repeats on every 407 (roughly once per minute, driven by the Pusher keepalive + reconnect cycle) for the entire stuck window.

Mechanism reference (generic log signatures)

• Gap detected: lastUpdateIDFromClient is less than the previousUpdateID received, client needs updating
• Response buffered, not applied: [Onyx] set called for key: onyxUpdatesFromServer ... hasChanged: true
• Sign-in returned 200 but no session update: exactly one session merge (before the 200, hasChanged:false); none after.
• No gap-fill issued: no GetMissingOnyxUpdates / ReconnectApp fetch to close the gap in the window.
• Reauth aborts: [Reauthenticate] Authentication with shortLivedToken is in progress. Re-authentication aborted. with accountIsLoading: 1.
• Loop: OpenApp / SearchForTodos / Search / OpenReport / PusherPing / AuthenticatePusher → jsonCode: 407, repeating.

Confirmed repro (devtools / Onyx) — reproduces the stuck loop

Sign in to NewDot web, let it load, then in the console:

Onyx.set('OnyxUpdatesLastUpdateIDAppliedToClient', 1)                                   // (1) force a gap
Onyx.merge('session', {authToken: 'dead-token', signedInWithShortLivedAuthToken: true}) // (2) dead token + transition flag
Onyx.merge('account', {isLoading: true})                                                // (3) isLoading !== false → abort branch
Onyx.set('isAuthenticatingWithShortLivedToken', true)                                    // (4) makes reauth ABORT, not redirect
Onyx.merge('credentials', {autoGeneratedLogin: '', autoGeneratedPassword: ''})           // (5) block reauth rescue

Then toggle offline→online (or refocus the tab). Expected: 407 loop + Re-authentication aborted, stuck loader, no logout.

The isAuthenticatingWithShortLivedToken + account.isLoading guard is what converts a clean logout into the infinite loop; the stale OnyxUpdatesLastUpdateIDAppliedToClient is what prevents the new auth from ever landing.

Fix directions

1. Apply sign-in auth state inline, bypassing gap-detection. A sign-in bootstraps auth; its authToken/encryptedAuthToken/logins must be applied immediately and never deferred behind a GetMissingOnyxUpdates that itself requires auth. (Primary.)
2. Escape hatch in the short-lived abort guard (Reauthentication.ts:179-190): if the transition never completes (token dead, updates never applied), stop aborting — recover or redirect rather than loop forever.
3. Gate the queue on sign-in completion (defense-in-depth): don't run API requests/reads until sign-in lands a changed authToken.

---

Next steps

• Try to reproduce real life scenario a couple more times
• Prepare PR with fixes mentioned above

[VickyStash]

I'll be OOO till Monday, and will prioritize this as soon as I'm back!

[VickyStash]

After several tries I was able to narrow down the scenario to more realistic one and reproduced the issue.
It allowed me narrow down concrete solution.
More details, steps and before/after videos can be found in the PR: #97097

[melvin-bot]

Triggered auto assignment to @inimaga, see https://stackoverflow.com/c/expensify/questions/7972 for more details.