[$250] Safari stuck loading on New Expensify

[m-natarajan]

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.73-4
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @abbagail
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

Issue: 1

1. login into Expensify in Classic or directly to New Expensify
2. wait for the page to load

Issue: 2

1. Login in to Expensify Classic
2. switch to New Expensify
3. refresh the page
4. wait for New Expensify to load

Expected Result:

Page loads, and you're able to start working

Actual Result:

Page never loads. Even after trying to clean sign out and clearing cache and cookies. Sutck on the green E loading screen

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshot for the issue is in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056434464843697407
• Upwork Job ID: 2056434464843697407
• Last Price Increase: 2026-07-06

[exfy-zapier]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[melvin-bot]

📣 @exfy-zapier! 📣
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>

[annaweber830]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-18 18:51:00 UTC.

Proposal

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

On Safari (macOS), New Expensify gets stuck on the green loading screen indefinitely. The splash screen never hides even after clearing cache and cookies.

What is the root cause of that problem?

The splash is gated on shouldHideSplash, which requires hasAttemptedToOpenPublicRoom to be true. That flag only flips after Report.doneCheckingPublicRoom() is called from DeepLinkHandler. Both call sites in DeepLinkHandler are inside a useEffect whose body only runs once isLoadingOnyxValue returns false:

DeepLinkHandler.tsx#L40-L43

if (isLoadingOnyxValue(allReportsMetadata, sessionMetadata, conciergeReportIDMetadata, introSelectedMetadata, isSelfTourViewedMetadata, betasMetadata)) {
    return;
}

allReportsMetadata comes from ONYXKEYS.COLLECTION.REPORT — the largest collection in Onyx. On Safari, ITP and stricter IndexedDB policies can leave this collection in status: 'loading' for an extended period or indefinitely. When that happens, the return fires on every render, Linking.getInitialURL() is never called, doneCheckingPublicRoom() is never called, and the splash never hides.

The safety-net effect below also cannot help:

DeepLinkHandler.tsx#L131-L136

useEffect(() => {
    if (!isAuthenticated || !initialUrlProcessed.current) {
        return;
    }
    Report.doneCheckingPublicRoom();
}, [isAuthenticated]);

initialUrlProcessed.current is only set inside the blocked effect, so this safety net is also a no-op when the main effect never runs.

This is a regression introduced by PR #89745 (commit 6a10132bdb1), which expanded the loading gate from isLoadingOnyxValue(sessionMetadata, isSelfTourViewedMetadata) to include allReportsMetadata, conciergeReportIDMetadata, introSelectedMetadata, and betasMetadata. The report collection was not needed in the gate — openReportFromDeepLink() already handles missing report data internally and waits for specific report keys when necessary. Adding allReportsMetadata to the gate made the splash screen's lifetime depend on the entire report collection hydration, which can stall on Safari.

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

Remove allReportsMetadata from the isLoadingOnyxValue check and from the effect's dependency array. allReports still needs to be subscribed to (it is passed into openReportFromDeepLink), but its loading status does not need to gate URL resolution — openReportFromDeepLink handles the undefined/partial case itself.

File: src/DeepLinkHandler.tsx

DeepLinkHandler.tsx#L31

Current code:

const [allReports, allReportsMetadata] = useOnyx(ONYXKEYS.COLLECTION.REPORT);

Updated code:

const [allReports] = useOnyx(ONYXKEYS.COLLECTION.REPORT);

DeepLinkHandler.tsx#L40

Current code:

if (isLoadingOnyxValue(allReportsMetadata, sessionMetadata, conciergeReportIDMetadata, introSelectedMetadata, isSelfTourViewedMetadata, betasMetadata)) {

Updated code:

if (isLoadingOnyxValue(sessionMetadata, conciergeReportIDMetadata, introSelectedMetadata, isSelfTourViewedMetadata, betasMetadata)) {

DeepLinkHandler.tsx#L114-L124

Current code:

    }, [
        conciergeReportID,
        introSelected,
        betas,
        allReportsMetadata.status,
        sessionMetadata.status,
        conciergeReportIDMetadata.status,
        introSelectedMetadata.status,
        isSelfTourViewedMetadata.status,
        betasMetadata.status,
    ]);

Updated code:

    }, [
        conciergeReportID,
        introSelected,
        betas,
        sessionMetadata.status,
        conciergeReportIDMetadata.status,
        introSelectedMetadata.status,
        isSelfTourViewedMetadata.status,
        betasMetadata.status,
    ]);

With this change the isLoadingOnyxValue guard clears as soon as session, concierge ID, intro selection, self-tour flag, and betas are ready — none of which depend on the full report collection. allReports is still passed to openReportFromDeepLink as the available snapshot, and that function's own per-report wait logic handles the case where a specific report hasn't loaded yet. The splash is no longer held hostage by COLLECTION.REPORT hydration time.

Only one file changes. No new state, no timeout heuristics, no behaviour change for the deep-link flow itself.

[MelvinBot]

Proposal

What is the root cause of that problem?

The app gets stuck on the green "E" splash screen because the splash screen can only be hidden once all three gates in Expensify.tsx:139 resolve:

const shouldInit = isNavigationReady && hasAttemptedToOpenPublicRoom && !!preferredLocale;

If any one of these stalls, the splash screen stays visible indefinitely. The most likely culprit for Safari on macOS is the isCheckingPublicRoom gate (which controls hasAttemptedToOpenPublicRoom). This Onyx key RAM_ONLY_IS_CHECKING_PUBLIC_ROOM defaults to true and must be explicitly set to false after the public room check completes. If the network request fails silently or the finallyData callback is dropped (as was confirmed in the related #85763), this gate never opens and the splash screen stays stuck.

A secondary Safari-specific factor is that Safari has stricter IndexedDB behavior (disabled in private browsing, lower storage quotas, incomplete clearing via DevTools). If Onyx's persistence layer (backed by IndexedDB) fails to initialize, preferredLocale may also never resolve, creating a second blocking gate.

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

This issue needs reproduction data first. The codebase already has built-in telemetry for exactly this scenario — the startBootsplashMonitor fires a Sentry warning every 10 seconds while the splash screen is still visible, logging the exact gate status (isCheckingPublicRoom, preferredLocale, isNavigationReady, etc.).

Recommended next steps:

1. Check Sentry for [BootSplash] splash screen is still visible warnings from Safari user agents around the time this was reported — the extra data will show exactly which gate is stuck
2. If isCheckingPublicRoom is the stuck gate: the fix from [$250] Navigation- Web page stuck on logo when navigating to IOU while logout #85763 (PR [CP Staging] Revert "[No QA] Fix lost/duplicated requests in PersistedRequests (Issues 2, 3, 4, 5)" #85804) addressed a race condition in PersistedRequests and a reauthentication middleware issue that could drop the finallyData that sets this flag to false. Verify whether those fixes are included in v9.3.73-4, or if this is a recurrence on a different code path
3. If preferredLocale is the stuck gate: add a timeout/fallback for locale loading that defaults to en if IndexedDB is unavailable (Safari private browsing scenario)

What alternative solutions did you explore? (Optional)

A defensive timeout that force-hides the splash screen after N seconds was considered, but this would mask the root cause and could lead to a broken app state (rendering before data is ready). The telemetry-first approach is preferred since the instrumentation already exists.

Related issues

• [$250] Navigation- Web page stuck on logo when navigating to IOU while logout #85763 — Web page stuck on logo during logout navigation. Root cause was a race condition in PersistedRequests.ts that dropped finallyData, leaving IS_CHECKING_PUBLIC_ROOM stuck at true. Fixed in PR [CP Staging] Revert "[No QA] Fix lost/duplicated requests in PersistedRequests (Issues 2, 3, 4, 5)" #85804.
• Android App Stuck on Loading Splash Screen (Infinite Loading) #79386 — Android stuck on splash screen. Root cause was a zombie React fragment after process death. Fixed in Mobile-Expensify PR Fix styled text treated as an emoji #13905. Different mechanism but same symptom.

---

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 - @abdulrahuman5196 (External)

[melvin-bot]

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

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

Expensify cannot mount NavigationRoot or hide the splash until the public-room gate has completed. That is visible in shouldInit and the NavigationRoot mount guard at Expensify.tsx#L293-L300.

That gate is opened by DeepLinkHandler, but DeepLinkHandler currently returns before it even calls Linking.getInitialURL() while any listed Onyx metadata is still loading, including the entire report collection at DeepLinkHandler.tsx#L31-L41. Because the call to Report.doneCheckingPublicRoom() is inside the URL-resolution path at DeepLinkHandler.tsx#L54-L83, a slow or stuck ONYXKEYS.COLLECTION.REPORT hydration prevents the public-room gate from opening at all.

The report collection does not need to finish hydrating before startup URL resolution can begin. openReportFromDeepLink() already handles missing report data by waiting for the specific report key when necessary at Link.ts#L330-L363. Blocking on the whole report collection before resolving the initial URL is what leaves Safari stuck on the green loading screen.

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

Remove allReportsMetadata from the DeepLinkHandler loading gate and dependency list.

That keeps the existing deep-link flow intact, but stops the startup splash from depending on the full report collection hydration status. allReports can still be passed into openReportFromDeepLink() as the currently available snapshot, and the report-specific fallback in openReportFromDeepLink() will continue to handle missing report data.

Required changes:

• Keep subscribing to ONYXKEYS.COLLECTION.REPORT for the current allReports snapshot.
• Stop destructuring allReportsMetadata.
• Remove allReportsMetadata from isLoadingOnyxValue(...).
• Remove allReportsMetadata.status from the effect dependency list.

Tests to add:

• Add a focused unit test for DeepLinkHandler where allReportsMetadata.status is loading but the other required metadata is loaded, then assert that Linking.getInitialURL() is still called and Report.doneCheckingPublicRoom() runs when the initial URL is null.
• Add a second case where an initial URL exists and openReportFromDeepLink() still receives the current allReports snapshot.

A timeout fallback was proposed in the issue thread. That would eventually unblock the splash, but it still leaves the incorrect dependency in place and makes affected users wait for the timeout on normal startup. This proposal is not a duplicate because it removes the unnecessary report-collection loading gate instead of masking it with a delayed fallback.

The telemetry-first proposal is useful for confirming which splash gate is stuck in Sentry, but it does not fix the App-side root cause.

What alternative solutions did you explore? (Optional)