[$250] [DEV] Infinite loading when switching to Inbox

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.41-4 (DEV only)
Reproducible in staging?: Needs Reproduction
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: @bernhardoj
Slack conversation (hyperlinked to channel name): #expensify_bugs

Action Performed:

1. Go to New Expensify on Dev
2. Open Inbox

Expected Result:

A report is shown

Actual Result:

Infinite loading. The report URL doesn't have reportID

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

w.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080712484395675250
• Upwork Job ID: 2080712484395675250
• Last Price Increase: 2026-07-24

[MelvinBot]

Proposal

What is the root cause of that problem?

On a cold Onyx cache (common on DEV / after clearing storage), the Inbox mounts before reports are hydrated, so the initial reportID is never resolved and stays empty — leaving the report screen stuck on the loading skeleton with a URL of /r (no id).

The flow:

1. Opening the Inbox mounts ReportsSplitNavigator, which picks the initial reportID once in a useState initializer. If there's no reportID in the deep link / URL / transition, it calls findLastAccessedReport(...) and falls back to '' when that returns undefined — see ReportsSplitNavigator.tsx:36-60.
2. On a cold cache findLastAccessedReport returns undefined (its report cache is empty), so initialReportID = ''.
3. The only recovery is ReportRouteParamHandler, whose useFocusEffect retries findLastAccessedReport — but if reports still aren't loaded at focus time it hits an early return and never retries when reports finish loading. See ReportRouteParamHandler.tsx:43-54. Critically, it reads from the in-memory report cache but only subscribes to REPORT_NAME_VALUE_PAIRS, so a later reports load doesn't re-trigger it.
4. With reportID empty forever, ReportActions subscribes to report_undefined, report is always undefined, and it renders the loading skeleton indefinitely — ReportActions.tsx.

Why DEV-only, and how to confirm

Production usually has reports persisted in Onyx storage synchronously at mount, so the race rarely loses. DEV (fresh/cleared cache) starts cold, so the mount-vs-load race is much more likely — matching "Needs Reproduction" on staging/prod.

To confirm on a broken repro: the client Log.info("[ReportScreen] no reportID found in params, setting it to lastAccessedReportID: ...") at ReportRouteParamHandler.tsx:56 will be absent (early return was hit); on a healthy load it's present.

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

Make the empty-reportID recovery re-run once reports actually load, instead of firing only on focus and silently giving up. In ReportRouteParamHandler, subscribe to the reports collection (or a "reports finished loading" signal) so that when reports hydrate, findLastAccessedReport is retried and navigation.setParams({reportID}) backfills the missing id. That keeps the fast path unchanged and only adds a retry when the first attempt found nothing.

What alternative solutions did you explore? (Optional)

Recomputing the fallback in ReportsSplitNavigator isn't enough on its own — it's a one-time useState initializer by design (to avoid an O(n) scan on every render), so the fix belongs in the recovery handler that already exists for exactly this case.

Confidence & caveats

High confidence — the two central claims are verified against HEAD (ea66d536): the empty-string fallback in ReportsSplitNavigator and the early-return-with-no-retry in ReportRouteParamHandler. Remaining unknown is dating the regression relative to the ReportScreen → ReportRouteParamHandler/ReportActions split refactor; a git blame on the early-return would pin that down.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.