[Bug]: Report not in sidebar shows "Hmm... it's not here" when opened via direct URL (race between ReportNotFoundGuard and ReportFetchHandler)

[MelvinBot]

Summary

A report that is not in the user's sidebar (LHN) can incorrectly show the "Hmm... it's not here" (NOT FOUND) page when opened via a direct URL/deep link in New Expensify — even though the report is fully accessible and the backend returns a valid OpenReport response.

This was diagnosed from a customer report where a specific expense report loaded fine in Expensify Classic but showed "not here" in New Expensify. Chrome DevTools confirmed that no OpenReport API call is made at all — the client decides "not found" purely from Onyx state, with no server request.

Root cause

A race condition introduced when ReportScreen.tsx was decomposed into ReportNotFoundGuard + ReportFetchHandler as separate components. The guard evaluates !isLoading && !reportExists in a render cycle before ReportFetchHandler's useEffect fires openReport. For reports not in the sidebar (loaded via direct URL), this produces a false "not here" page.

The original monolithic ReportScreen had the not-found check and the fetch trigger co-located, which provided implicit ordering guarantees (fetch fired before the guard evaluated). The decomposition broke that coupling.

Problematic flow

1. User navigates to a report not in their sidebar (via deep link/URL)
2. OpenApp/ReconnectApp completes → IS_LOADING_REPORT_DATA = false
3. Report isn't in the OpenApp response (not a sidebar report) → reportExists = false
4. ReportNotFoundGuard sees !isLoading && !reportExists → shows NOT FOUND
5. ReportFetchHandler's useEffect either hasn't fired yet, or hits an early return

Key code locations

• ReportNotFoundGuard.tsx:54 — the shouldShowNotFoundPage = !isLoading && !reportExists decision
• ReportNotFoundGuard.tsx:47-53 — isLoading combines IS_LOADING_APP, IS_LOADING_REPORT_DATA, and isLoadingInitialReportActions (the last is RAM-only and defaults to true when undefined)
• ReportFetchHandler.tsx:111-135 — the fetch trigger with three early-return conditions that can skip calling openReport

Impact

Not specific to a single user or report. Any report not in the user's sidebar that is accessed via a direct URL can hit this race. This includes deep links, bookmarks, and shared report links.

Repro

1. Find a report that is not in the LHN/sidebar (e.g. a submitted/archived expense report on a workspace where you're an admin but the report doesn't surface in the sidebar)
2. Navigate to it via direct URL in New Expensify (web)
3. Observe the "Hmm... it's not here" page despite having access. The same report loads fine in Expensify Classic.

Note: opening DevTools before navigating and filtering Network by api.php shows that no OpenReport call is fired.

Platform

Web (Chrome). Likely affects all platforms since the logic is shared client-side code.

Issue Owner

Current Issue Owner: @dukenv0307

[harryautomazione]

Proposal

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

When a user opens a report via direct URL or deep link — a report that is not in their sidebar — New Expensify shows the "Hmm... it's not here" page even though the report is fully accessible. No OpenReport API call is fired at all; the client decides "not found" purely from Onyx state.

What is the root cause of that problem?

The RAM_ONLY_REPORT_LOADING_STATE Onyx key is memory-only and is not reset between navigations. If the user has previously visited the same report, that key already exists in RAM with isLoadingInitialReportActions: false. When they return via direct URL, ReportNotFoundGuard computes isLoading in the same render cycle where IS_LOADING_APP and IS_LOADING_REPORT_DATA are both already false. Because isLoadingInitialReportActions is stale false, isLoading resolves to false. Since the report is not in the sidebar, reportExists is also false, so shouldShowNotFoundPage becomes true and the error page renders — all before ReportFetchHandler's useEffect has had a chance to call openReport. The = true fallback in useOnyx only protects first-time visits where the RAM key is absent; it does not protect against this stale false scenario from a prior visit.

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

In ReportFetchHandler, when reportIDFromRoute changes (or on initial mount), optimistically reset isLoadingInitialReportActions to true in RAM_ONLY_REPORT_LOADING_STATE for that reportID before the fetch useEffect runs. This ensures ReportNotFoundGuard always sees isLoading = true in every render cycle that precedes the actual openReport response, regardless of any stale RAM state left over from a prior visit.

What alternative solutions did you explore? (Optional)

Introducing a shared React context ref between ReportFetchHandler and ReportNotFoundGuard (e.g. isFetchScheduled) to signal that a fetch is pending. This avoids touching Onyx but introduces coupling between the two components. Fixing the state at the source is cleaner.

[elirangoshen]

Hi, Im Eliran form Callstack and I can work on this issue @mountiny

[elirangoshen]

Update: I started to investigate and checking new lead.

[elirangoshen]

I didn't reproduce it yet, can you give me sample how to ? maybe via video ?

[melvin-bot]

Whoops! This issue is 2 days overdue. Let's get this updated quick!

[elirangoshen]

I've opened a pr
#93415

please assign me btw :)
@mountiny