Generic 'Unexpected error' shown instead of re-authentication when auth token expires during expense split

[MelvinBot]

Bug: Generic "Unexpected error" shown instead of re-authentication when auth token expires during expense split

Slack thread: https://expensify.slack.com/archives/C049HHMV9SM/p1778034168209899

Description

When a user's auth token expires while they are actively using the app, API write commands (e.g., splitting an expense) fail with a generic "Unexpected error submitting this expense. Please try again later." message. The server returns jsonCode 407 (AuthTokenExpired), but the App does not detect this and does not trigger the ReauthenticateSession flow. The user appears fully logged in and can browse cached data, but all API writes silently fail.

Steps to Reproduce

1. Log into NewDot web with an active session
2. Wait for auth token to expire naturally (or let session sit idle)
3. Open a report and select an expense
4. Attempt to split the expense
5. Observe the generic error message
6. Retry — same result

Expected Behavior

The App should detect the 407 AuthTokenExpired response, automatically trigger ReauthenticateSession to refresh the token, and either retry the operation transparently or prompt the user to sign in again with the server's actual error message.

Actual Behavior

The App displays "Unexpected error submitting this expense. Please try again later." — it does not surface the real error (AuthTokenExpired) and does not trigger the auto-reauthentication flow. The user appears logged in and can browse cached data, but ALL API write commands fail with 407. In the observed case, this persisted for ~9 minutes until a full Authenticate eventually fired (no ReauthenticateSession was ever triggered).

Log Evidence

• First attempt: request_id 9f74508e2ca27e99-BOS (01:47 UTC, 2026-05-06)
• Second attempt: request_id 9f7455822c1c7e99-SJC (01:50 UTC, 2026-05-06)
• Both returned jsonCode 407, AuthTokenExpired
• During the 01:40–01:59 UTC window, virtually every API command (OpenReport, Search, PusherPing, AuthenticatePusher, Transaction_Split) was returning 407

Platform

Web (v9.3.66-7)

Possibly Related Issues

• [$250] Severe Auth Issues on Mobile: Login Failures, Frequent Logouts, and Inability to Log Out #89613 — Severe auth issues on mobile (different platform/symptoms but related auth area)

[mountiny]

@MelvinBot Was the user able to complete other actions or were they stuck in this state where the app looked like its working due to the offline first setup, but actually all the other requests failed?

[MelvinBot]

The user was stuck. As noted in the issue's log evidence, during the 01:40–01:59 UTC window (~19 minutes), virtually every API command was returning 407 — not just Transaction_Split, but also OpenReport, Search, PusherPing, AuthenticatePusher, etc.

The app appeared functional due to offline-first: cached data was browsable (reports, expenses), so it looked like it was working. But all server-side operations (writes and reads requiring fresh data) were silently failing. The user was effectively in a read-only ghost state with no indication that their session had expired, until a full Authenticate eventually fired ~9 minutes later (no ReauthenticateSession was ever triggered).

[mountiny]

@MelvinBot Did they user have to sign out and sign back in or how did they recover?

[MelvinBot]

The user did not have to sign out. Based on the logs, a full Authenticate call eventually fired on its own ~9 minutes after the 407s started (around 01:49–01:50 UTC), which refreshed the session and restored functionality. No ReauthenticateSession was ever triggered — the recovery happened via a standard Authenticate call, not the expected auto-reauthentication flow.

So the user was stuck in the broken state for roughly 9 minutes until the app happened to re-authenticate on its own.

[mountiny]

@MelvinBot What flow triggers the Authenticate call in the App without the user signing out?

[MelvinBot]

There are two flows that trigger Authenticate automatically without the user signing out:

1. Reauthentication Middleware (407 response handler)
When any API request returns jsonCode 407 (NOT_AUTHENTICATED), the Reauthentication middleware intercepts it and calls reauthenticate(), which makes a fresh Authenticate API call using stored credentials (autoGeneratedLogin/autoGeneratedPassword). Queued requests are then retried with the new token.

2. Attachment Image Reauthenticator (client-side session expiry check)
When the app tries to load an auth-required image (attachments/receipts), the Image component checks if the session is older than 2 hours via isExpiredSession(). If expired, it activates the AttachmentImageReauthenticator, which calls reauthenticate() after a 3.5-second delay.

In the case from this issue, the middleware (flow 1) is the one that should have fired when the 407s started — but it didn't trigger ReauthenticateSession or Authenticate for ~9 minutes. The eventual recovery was likely an image load (flow 2) detecting the expired session and triggering Authenticate independently.

[mountiny]

@MelvinBot Are you able to figure that out from the logs? Which patch was taken? Can you analyse where is a bug in the flow 1 that it took 9 minutes to reauthenticate?

[MelvinBot]

I wasn't able to query production logs directly (VictoriaLogs wasn't accessible), so I can't confirm which path triggered the eventual recovery. However, the code analysis reveals a clear bug in flow 1 that explains the 9-minute delay.

Bug in the Reauthentication Middleware

The credential guard in reauthenticate() has been intentionally commented out, causing a cascading failure that permanently blocks the network queue.

At Reauthentication.ts:140-147:

if (!credentials?.autoGeneratedLogin || !credentials?.autoGeneratedPassword) {
    Log.info('[Reauthenticate] No credentials available, redirecting to sign in');
    // The following lines are commented out to test if it's the cause of #fireroom-2026-01-28-user-signout
    // setIsAuthenticating(false);
    // redirectToSignIn('No credentials available');
    // return false;
}

When credentials are missing, this guard logs but does not return. The cascading effect:

1. setIsAuthenticating(true) is called, blocking all MainQueue requests
2. Authenticate() is called with undefined partnerUserID/partnerUserSecret
3. requireParameters throws → caught → returns Promise.resolve() (undefined)
4. Back in reauthenticate(), the !response check at line 163 returns false — but never calls setIsAuthenticating(false)
5. The NetworkStore isAuthenticating flag is now permanently stuck true, blocking all requests via MainQueue.canMakeRequest()

The middleware-level promise (line 24-27) resets correctly via .finally(), so new 407s from already-in-flight requests can trigger new reauthenticate() calls — but each attempt hits the same dead end, creating a loop of failed reauthentication attempts that never unblocks the queue.

If credentials were present (more likely in this case since the user had an active session), the Authenticate API call would actually fire. If the server returned UNABLE_TO_RETRY (network-level failure), the retryReauthenticate loop retries up to 10 times with exponential backoff (10ms→10s), which could account for a multi-minute delay.

What would confirm this from logs

Search for the user's accountID (extractable from request IDs 9f74508e2ca27e99-BOS / 9f7455822c1c7e99-SJC) and look for:

• command=Authenticate in the 01:40–02:00 UTC window → confirms which path triggered recovery
• command=ReauthenticateSession → confirms whether the middleware ever fired
• The successful Authenticate response → its timing tells us exactly how long the queue was blocked

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

[mountiny]

Maybe this would be fixed with this one #89680