[$250] Navigation- Web page stuck on logo when navigating to IOU while logout

[nlemma]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.40-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-10400/folder/13176964/41237746/1260625160
Email or phone of affected tester (no customers): emady.syed1234+newuser@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11 / Chrome
App Component: Other

Action Performed:

1. Open https://staging.new.expensify.com/
2. Create a new expense via + icon with any user
3. Open expense report > View details > Share link and copy the IOU link
4. Logout and paste link in browser

Expected Result:

Web page should navigate to login screen

Actual Result:

Web page stuck on logo

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7106297_1773843361946.stuck.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @dukenv0307

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034597830456948753
• Upwork Job ID: 2034597830456948753
• Last Price Increase: 2026-03-19

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a logged-out user navigates to an IOU/expense report deep link (e.g., https://staging.new.expensify.com/r/12345), the web page gets stuck on the Expensify logo (splash screen) instead of redirecting to the sign-in page.

What is the root cause of that problem?

The splash screen is gated behind the IS_CHECKING_PUBLIC_ROOM Onyx key, which defaults to true and must be set to false before the app renders NavigationRoot (and thus the sign-in page). For deep link report URLs from unauthenticated users, the app makes an OpenReport API call to check if it's a public room, with IS_CHECKING_PUBLIC_ROOM=false in the finallyData.

The problem is a race condition between Onyx.clear() and the finallyData application:

1. The server returns 407 (NOT_AUTHENTICATED) for the OpenReport request
2. The Reauthentication middleware attempts to reauthenticate, but fails because there are no credentials (the user is logged out). During this failure, redirectToSignIn() is called inside Authenticate() (src/libs/Authentication.ts:75), which triggers Onyx.clear()
3. Onyx.clear() wipes IS_CHECKING_PUBLIC_ROOM (it's not in keysToPreserve in src/libs/actions/SignInRedirect.ts:51-58), resetting it to its default value of true
4. Meanwhile, the finallyData from the OpenReport response sets IS_CHECKING_PUBLIC_ROOM=false, but this is applied via queueOnyxUpdates (deferred) and can be overwritten by the concurrent Onyx.clear()
5. Onyx.clear() also clears the session, which causes the DeepLinkHandler effect to re-run (it depends on sessionMetadata?.status — src/DeepLinkHandler.tsx:75), calling openReportFromDeepLink() again and restarting the cycle

A contributing factor is that the early exit for missing credentials in src/libs/Authentication.ts:133-140 is commented out (disabled for debugging #fireroom-2026-01-28-user-signout), so the code always attempts the full Authenticate call even when autoGeneratedLogin/autoGeneratedPassword are undefined, which then hits requireParameters → throws → redirectToSignIn().

Key code locations:

• src/Expensify.tsx:68 — IS_CHECKING_PUBLIC_ROOM defaults to true with initWithStoredValues: false, gates NavigationRoot rendering at line 305
• src/libs/actions/Link.ts:245-264 — openReportFromDeepLink calls openReport() for unauthenticated users with reportID; doneCheckingPublicRoom() is NOT called directly (only if offline)
• src/libs/actions/Report/index.ts:1675-1682 — IS_CHECKING_PUBLIC_ROOM=false is in finallyData of the OpenReport WRITE command
• src/libs/Authentication.ts:62-76 — Authenticate calls redirectToSignIn when requireParameters throws due to missing credentials
• src/libs/Authentication.ts:133-140 — Early exit for missing credentials is commented out

What changes do you think we should make in order to solve the problem?

Add skipReauthentication: true to the OpenReport parameters when isFromDeepLink is true, in src/libs/actions/Report/index.ts (around line 1537-1539, alongside the existing shouldRetry = false):

if (isFromDeepLink) {
    parameters.shouldRetry = false;
    parameters.skipReauthentication = true;
}

This prevents the Reauthentication middleware from attempting to reauthenticate (and thus triggering redirectToSignIn → Onyx.clear()). Instead, the 407 response flows through to SaveResponseInOnyx, which correctly applies failureData and finallyData, setting IS_CHECKING_PUBLIC_ROOM=false. The splash screen then hides and the sign-in page renders.

This is safe because the deep link OpenReport call is specifically checking whether the report is a public room — if the user isn't authenticated and it's not a public room, the correct behavior is to show the sign-in page, not to attempt reauthentication.

What alternative solutions did you explore? (Optional)

1. Add IS_CHECKING_PUBLIC_ROOM to keysToPreserve in clearStorageAndRedirect() — This would prevent Onyx.clear() from resetting the key, but doesn't address the DeepLinkHandler re-run loop caused by session clearing.
2. Call doneCheckingPublicRoom() immediately after openReport() for unauthenticated users — This would break the public room experience, where unauthenticated users should be able to view public rooms without signing in.
3. Re-enable the commented-out early exit in Authentication.ts:133-140 — This should also be done as a separate cleanup, but alone it doesn't fully fix the issue since redirectToSignIn is still called in the requireParameters catch block.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @dukenv0307 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022034597830456948753

[twilight2294]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a logged-out user navigates to an IOU report deep link (e.g., https://staging.new.expensify.com/r/12345), the web page gets permanently stuck on the Expensify logo splash screen instead of showing the sign-in page.

What is the root cause of that problem?

The splash screen is gated on the IS_CHECKING_PUBLIC_ROOM Onyx key, which defaults to true and must be set to false before NavigationRoot renders. In Expensify, isCheckingPublicRoom defaults to true with initWithStoredValues: false, and at line 305, NavigationRoot only renders once hasAttemptedToOpenPublicRoom becomes true — which requires isCheckingPublicRoom to flip to false.

When the deep link is processed, openReportFromDeepLink() in Link calls openReport() for unauthenticated users with a report ID. The openReport() function in Report correctly places IS_CHECKING_PUBLIC_ROOM = false in finallyData, which by contract should execute regardless of whether the API call succeeds or fails.

However, the actual bug is in SequentialQueue. When the unauthenticated OpenReport request fails after exhausting retries, the .catch() handler only applies failureData — finallyData is completely dropped:

.catch(() => {
    Onyx.update(requestToProcess.failureData ?? []);
    // ❌ finallyData is never applied here!
});

This violates the finallyData contract. Notably, the shouldFailAllRequests branch at line 204-211 correctly includes both failureData and finallyData, proving this is an oversight rather than intentional behavior. The result is IS_CHECKING_PUBLIC_ROOM stays true forever, the splash screen never hides, and the user is stuck.

What changes do you think we should make in order to solve the problem?

Apply finallyData alongside failureData in the max-retry failure path of SequentialQueue, matching the existing correct pattern at line 206:

 // Line 252 — max-retry failure catch handler
-.catch(() => {
+.catch((error) => {
     Log.info('[SequentialQueue] Request failed too many times, giving up', false, { ... });
-    Onyx.update(requestToProcess.failureData ?? []);
+    Onyx.update([...(requestToProcess.failureData ?? []), ...(requestToProcess.finallyData ?? [])]);
     endPersistedRequestAndRemoveFromQueue(requestToProcess);

The same fix should be applied at line 227 (the RESEND_VALIDATE_CODE throttle case) for consistency:

-    Onyx.update(requestToProcess.failureData ?? []);
+    Onyx.update([...(requestToProcess.failureData ?? []), ...(requestToProcess.finallyData ?? [])]);

What alternative solutions did you explore? (Optional)

The existing proposal suggests adding skipReauthentication: true to the OpenReport call when isFromDeepLink is true. While this would prevent the reauthentication loop, it works around the symptom rather than fixing the root cause. The fundamental issue is that finallyData — which is supposed to always run (like a finally block) — is silently dropped in the max-retry failure path. This same bug could affect any future API call that relies on finallyData for cleanup in a failure scenario. Fixing it at the SequentialQueue level is a two-line change that restores the correct finallyData contract and aligns with the pattern already used in the shouldFailAllRequests branch at line 206.

[melvin-bot]

📣 @VanshDevChoudhary! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[shivang-goliyan]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a logged-out user navigates to an IOU deep link, the web page gets stuck on the Expensify logo splash screen. The sign-in page never appears because IS_CHECKING_PUBLIC_ROOM stays true forever, preventing NavigationRoot from rendering (Expensify.tsx:305).

What is the root cause of that problem?

The Reauthentication middleware unnecessarily attempts re-authentication for deep link OpenReport requests from unauthenticated users.

When isFromDeepLink is true, openReport() sets shouldRetry = false (Report/index.ts:1532-1534) but does NOT set skipReauthentication. When the server returns 407, the middleware check at Reauthentication.ts:78-79 — (!shouldRetry && !apiRequestType) || skipReauthentication — evaluates to false because apiRequestType is set (it's a WRITE command). So reauthentication proceeds.

From there the cascade is: reauthenticate() → Authenticate() with undefined credentials → requireParameters() throws → redirectToSignIn() → Onyx.clear() → IS_CHECKING_PUBLIC_ROOM reset to true (it's not in keysToPreserve in SignInRedirect.ts:51-58). The reauthentication resolves with false, the middleware returns undefined back to SequentialQueue, and SequentialQueue's .then() handler fires (not .catch()). Since the response is undefined, SaveResponseInOnyx never runs, so finallyData — which contains IS_CHECKING_PUBLIC_ROOM = false — is never applied. The splash screen stays forever.

Onyx.clear() also wipes the session, which triggers DeepLinkHandler's useEffect (line 75, depends on sessionMetadata?.status) to re-run openReportFromDeepLink(), creating an infinite loop.

This regression traces back to PR #64280 (June 2025), which changed the Reauthentication middleware to return false on failure instead of retrying infinitely. That fixed a re-auth loop but introduced this silent failure path. A contributing factor is the commented-out early exit in Authentication.ts:134-140 (disabled for debugging #fireroom-2026-01-28-user-signout), though re-enabling it alone wouldn't fix this — redirectToSignIn() is still called in the catch block at line 64-76.

What changes do you think we should make in order to solve the problem?

Add skipReauthentication: true alongside the existing shouldRetry = false in Report/index.ts:1532-1534:

if (isFromDeepLink) {
    parameters.shouldRetry = false;
    parameters.skipReauthentication = true;
}

And add skipReauthentication?: boolean to OpenReportParams.ts.

With this, the middleware skips re-auth entirely, the 407 flows through to SaveResponseInOnyx which applies failureData and finallyData, IS_CHECKING_PUBLIC_ROOM becomes false, and the sign-in page renders. This follows the same pattern used by LogOut (LogOutParams.ts:7) and SignInWithShortLivedAuthToken (Session/index.ts:783) for the same reason — credentials are unavailable or irrelevant.

Edge cases: public room deep links are unaffected (they return 200, not 407). Authenticated users with expired tokens don't hit this path because doneCheckingPublicRoom() is called directly (Link.ts:263). Offline users are handled separately at Link.ts:258-259.

What alternative solutions did you explore? (Optional)

Adding IS_CHECKING_PUBLIC_ROOM to keysToPreserve in SignInRedirect.ts would prevent the reset, but doesn't stop the unnecessary reauthentication attempt, doesn't fix the dropped finallyData (the response is undefined from the middleware, not from SequentialQueue's .catch()), and doesn't prevent the DeepLinkHandler re-run loop.

The other proposal on this issue targets SequentialQueue's max-retry .catch() handler for not applying finallyData. That IS a valid infrastructure gap, but the max-retry .catch() is never reached here. The Reauthentication middleware resolves gracefully with false → returns undefined → SequentialQueue's .then() fires, not .catch(). Their fix wouldn't solve this bug.

[dukenv0307]

@twilight2294 I can't reproduce this issue on staging, can you please verify again?