[$250] Report opened via /search/r/ deep link shows only a semi-transparent skeleton loader with the Home page visible behind it

[yuwenmemon]

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.43-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: N/A
Email or phone of affected tester (no customers): yuwen@expensify.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Yuwen
Slack conversation (hyperlinked to channel name):

Action Performed:

1. Open a GitHub issue that contains OldDot report links of the form https://www.expensify.com/report?param={"pageReportID":"<reportID>"}. In the recording this was the AP-close "reports awaiting your approval/submission" reminder issue auto-generated by the alteryxbotify bot, where each "Approve report" / "Submit report" link uses that format.
2. While logged in to New Expensify, click one of those links. Because it's a www.expensify.com link handing off to New Expensify, it routes through the auth transition — https://new.expensify.com/transition?accountID=<id>&email=<email>&shortLivedAuthToken=<token>&exitTo=... — and then redirects to https://new.expensify.com/search/r/<reportID>.
3. Observe the report view on the /search/r/<reportID> route (reproduced on report IDs 236182401668712 and 238362409868712).

Note: the /transition hop is what triggers this. A link that points straight at new.expensify.com (rather than an OldDot www.expensify.com/report?param=... link) skips the transition and does not reproduce the bug.

Expected Result:

The report opens on the /search/r/<reportID> route and its contents (the report header and its transactions/expenses) render. Any loading placeholder shown beforehand is fully opaque.

Actual Result:

Only a skeleton-loading placeholder renders, and it never resolves into the actual report. The skeleton is semi-transparent, so the Home page (For you / Recently added / Your spend / Discover) is visible through it in the background. Reproduced on two different report IDs.

Workaround:

Not applicable.

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

Media to be attached by reporter.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022081972772766824621
• Upwork Job ID: 2081972772766824621
• Last Price Increase: 2026-07-28

[MelvinBot]

Proposal

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

A report opened via a /search/r/<reportID> deep link that first passes through the /transition auth flow renders only a semi-transparent skeleton loader that never resolves into the real report, with the Home page visible behind it.

What is the root cause of that problem?

Two things combine — one is the actual bug, the other explains the "see-through" symptom:

1. The skeleton never resolves (the real bug). The /search/r/:reportID route is SEARCH_MONEY_REQUEST_REPORT (ROUTES.ts:1285) → SearchMoneyRequestReportPage → MoneyRequestReportView. The skeleton is gated by shouldShowOpenReportLoadingSkeleton (isLoadingInitialReportActions) and a separate isAppLoadPending skeleton branch.

openReport sets isLoadingInitialReportActions: true in optimisticData (Report/index.ts:1584) but only flips it back to false in successData/failureData (1629 / 1650) — which for write commands are held in memory until the SequentialQueue flushes. In the transition flow, LogInWithShortLivedAuthTokenPage fires openApp and then navigates to exitTo (the report) without awaiting it (LogInWithShortLivedAuthTokenPage.tsx:74). openApp sets IS_LOADING_APP: true optimistically and clears it only in finallyData — and the code itself warns that an interrupted session can strand IS_LOADING_APP: true with no OpenApp left to clear it (App.ts:356-370). While IS_LOADING_APP/isLoadingInitialReportActions stay stuck, the report stays on the skeleton and can't even fall back to a NotFound page, because shouldShowAccessErrorPage early-returns false while isLoadingApp !== false.

2. Why the Home page shows through. The report screen lives in the RightModalNavigator, whose cards are intentionally transparent — the opaque background is painted by ScreenWrapperContainer via styles.appBG, not by the card or the skeleton (ReportActionsSkeletonView has no background of its own). During the transition window a semi-transparent FullScreenLoadingIndicator (opacity: 0.8) is also layered over Home. So while the screen is stuck loading and the opaque appBG layer isn't solidly covering the RHP area, Home remains visible behind the skeleton. This is a symptom of #1, not an independent bug.

Investigation details & evidence

• Skeleton gating: MoneyRequestReportView.tsx:169 and the isAppLoadPending branch just below it.
• isLoadingInitialReportActions lifecycle: optimistic true at Report/index.ts:1584; false only in success/failure data (held until queue flush).
• IS_LOADING_APP self-heal note explicitly describes the stuck-true failure mode: App.ts:356-370.
• NotFound suppressed while loading: SearchMoneyRequestReportPage.tsx:317-320.
• Transparency: RHP cards use a transparent card style; opacity comes from ScreenWrapperContainer's appBG; the skeleton contributes no background; FullScreenLoadingIndicator is opacity: 0.8 by design.

Alternative considered: a paused SequentialQueue (shouldPauseQueue in SaveResponseInOnyx) could equally leave OpenReport's success/failure data un-flushed, stranding isLoadingInitialReportActions: true even if IS_LOADING_APP clears. Both paths produce the identical symptom; production logs (did OpenApp/OpenReport for this reportID complete? was the queue paused?) would confirm which one fires.

Confidence: Medium — the code mechanism is clear and verified, but I have no production logs confirming which stall path actually triggers in the repro.

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

1. Guarantee the loading gates clear even on an interrupted transition. Ensure the transition flow's openApp (or the follow-up ReconnectApp, which already has shouldClearAppLoading self-healing in App.ts) reliably clears IS_LOADING_APP, and that openReport is (re)dispatched for the target report once the app finishes loading, so isLoadingInitialReportActions is driven to false by a real success/failure response rather than being stranded by an un-flushed queue.
2. Add a safety net so the screen can escape the skeleton. Relax the shouldShowAccessErrorPage guard at SearchMoneyRequestReportPage.tsx:317-320 (or the skeleton branches in MoneyRequestReportView) so a stuck isLoadingApp can't indefinitely block both the report and the NotFound fallback — e.g. time out the loading gate or key it off the actual OpenReport request state rather than the global app-loading flag.

What alternative solutions did you explore? (Optional)

Ensuring ScreenWrapperContainer's appBG always paints opaquely would fix only the cosmetic "see-through" symptom, not the underlying stuck-load, so it should not be the primary fix.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97159) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[shubham1206agra]

@yuwenmemon Can you make the steps more concrete please? I am not seeing any transition links when clicking from email.

[yuwenmemon]

@shubham1206agra updated the OP.

[shubham1206agra]

🆘 C+ Help Wanted

[lorretheboy]

Proposal

What is the root cause of that problem?

Two different places both handle the same OldDot transition link (/transition?...&exitTo=search/r/<reportID>), and they race each other.

When AuthScreens mounts, setUpPoliciesAndNavigate navigates to the exitTo route:

App/src/libs/actions/App.ts

Lines 865 to 869 in 71c5c9f

	if (!isLoggingInAsNewUser && exitTo) {
	Navigation.waitForProtectedRoutes().then(() => {
	Navigation.navigate(exitTo);
	});
	}

At the same time LogOutPreviousUserPage (the screen mounted for /transition) also fires Navigation.goBack(ROUTES.HOME) followed by its own Navigation.navigate(exitTo):

App/src/pages/LogOutPreviousUserPage.tsx

Lines 86 to 94 in 71c5c9f

	if (!CONFIG.IS_HYBRID_APP && exitTo !== ROUTES.WORKSPACE_NEW && !isAccountLoading && !isLoggingInAsNewUser) {
	Navigation.isNavigationReady().then(() => {
	// remove this screen and navigate to exit route
	Navigation.goBack(ROUTES.HOME);
	if (exitTo) {
	Navigation.navigate(exitTo as Route);
	}
	});
	}

— even though the file's own header comment says it must not navigate because App.setUpPoliciesAndNavigate owns that:

App/src/pages/LogOutPreviousUserPage.tsx

Lines 27 to 30 in 71c5c9f

	// This page is responsible for handling transitions from OldDot. Specifically, it logs the current user
	// out if the transition is for another user.
	//
	// This component should not do any other navigation as that handled in App.setUpPoliciesAndNavigate

The chain: the first navigate pushes the search/r/:reportID RHP → the interleaved goBack(ROUTES.HOME) (meant only to remove the /transition screen) rewrites the stack while the RHP open transition is still running → the second navigate dispatches the same RHP again, and because the top route is now already the RHP navigator, linkTo skips inserting the matching Search full-screen underneath, so Home stays as the background:

App/src/libs/Navigation/helpers/linkTo/index.ts

Lines 222 to 225 in 71c5c9f

	// If we deep link to a RHP page, we want to make sure we have the correct full screen route under the overlay.
	// Skip when current top is already RHP — the underlying tab is already in place, and the extra dispatch
	// would corrupt the navigation state. Issue: https://github.com/Expensify/App/issues/89006
	if (shouldCheckFullScreenRouteMatching(action) && currentState.routes[currentState.index]?.name !== NAVIGATORS.RIGHT_MODAL_NAVIGATOR) {

The interrupted push/pop leaves the report screen stuck mid-transition (hence the semi-transparent card with Home showing through), and a stack screen that is no longer the focused one is frozen and never re-renders — so the skeleton never turns into the report even after OpenReport returns data.

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

Make the exitTo navigation single-owner. Remove the goBack + navigate(exitTo) block from LogOutPreviousUserPage's second effect for the non-HybridApp flow (it duplicates what setUpPoliciesAndNavigate already does, per the file's own comment), and move the "remove /transition from history" step into setUpPoliciesAndNavigate — i.e. inside its existing waitForProtectedRoutes().then() call Navigation.goBack(ROUTES.HOME) (or navigate with forceReplace) immediately before Navigation.navigate(exitTo):

App/src/libs/actions/App.ts

Lines 865 to 869 in 71c5c9f

	if (!isLoggingInAsNewUser && exitTo) {
	Navigation.waitForProtectedRoutes().then(() => {
	Navigation.navigate(exitTo);
	});
	}

With one owner there is no second dispatch racing a goBack mid-animation, so the RHP is pushed once, on top of the correct Search full-screen, and renders the loaded report normally.

What alternative solutions did you explore? (Optional)

Keep both call sites but make them idempotent: guard each with an isActiveRoute(exitTo) check (and only goBack when the focused route is still SCREENS.TRANSITION_BETWEEN_APPS) so whichever fires second becomes a no-op. This works but leaves two owners of the same flow, which is how the race was introduced in the first place.

[aswin-s]

Proposal

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

When a report is opened on web via a cold transition/auth deep link (new.expensify.com/transition?... → new.expensify.com/search/r/<reportID>), the report page renders only a semi-transparent skeleton loader that never resolves into the report; the Home page (For you / Recently added / Your spend / Discover) is visible through it in the background. Expected: the /search/r/<reportID> route opens over the Search page with a fully-opaque placeholder that resolves into the report header and its transactions.

What is the root cause of that problem?

SEARCH_MONEY_REQUEST_REPORT (the screen behind /search/r/<reportID>) is a Right-Hand-Panel screen that is only ever meant to render on top of the SEARCH.ROOT full-screen page — it is declared as a child of SCREENS.SEARCH.ROOT in SEARCH_TO_RHP.ts:19, and the inverse relation RHP_TO_SEARCH (RELATIONS/index.ts:35) is what tells the navigator to place SEARCH.ROOT underneath the RHP. On the normal in-app path this is supplied explicitly — getReportURLForCurrentContext.ts:55-60 forces backTo to ROUTES.SEARCH_ROOT before building the SEARCH_MONEY_REQUEST_REPORT route. On a cold deep link through the transition flow there is no in-app navigation state and no backTo, so the linking adapter never materializes the SEARCH.ROOT backdrop; the RHP is placed over the default Home screen instead. Because the RHP is a semi-transparent overlay, Home shows through, and because the Search central screen never mounts, the query/report data behind the skeleton is never loaded — so it never resolves.

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

1. In src/libs/Navigation/helpers/getReportURLForCurrentContext.ts (lines 55-60), the guard already forces backTo to ROUTES.SEARCH_ROOT for the in-app path. Apply the same backdrop guarantee to the deep-link path by ensuring the linking adapter that resolves /search/r/:reportID (the SEARCH_MONEY_REQUEST_REPORT entry in linkingConfig/config.ts:2125) always yields SEARCH.ROOT as the underlying full-screen route when none is present in the incoming state — mirroring how other RHP relations resolve their parent via the RHP_TO_* inverse maps.

// when adapting a cold /search/r/ deep link with no underlying full-screen route,
// resolve the RHP's parent from RHP_TO_SEARCH and inject SEARCH.ROOT as the backdrop
const underlyingRoute = RHP_TO_SEARCH[SCREENS.RIGHT_MODAL.SEARCH_MONEY_REQUEST_REPORT]; // SCREENS.SEARCH.ROOT

2. Confirm the sibling RHP report screen SCREENS.RIGHT_MODAL.SEARCH_REPORT (SEARCH_TO_RHP.ts:20, config.ts:1961) is covered by the same fix — it shares the identical SEARCH.ROOT-parent relation and would exhibit the same transparent-over-Home symptom on a cold /search/r/ deep link.

Behavior matrix:

Entry path	Backdrop before	Backdrop after
In-app tap from Search (backTo set)	SEARCH.ROOT (opaque, resolves)	unchanged — SEARCH.ROOT
Cold transition deep link to /search/r/<id>	Home (transparent, never resolves)	SEARCH.ROOT (opaque, resolves)
Cold deep link to SEARCH_REPORT RHP	Home (transparent)	SEARCH.ROOT

What alternative solutions did you explore? (Optional)

Making MoneyRequestReportView's skeleton fully opaque (so Home no longer shows through) would mask the visual symptom but is the wrong layer — it does not restore the missing SEARCH.ROOT backdrop, so the query never runs and the skeleton would still never resolve into the report. The defect must be fixed where the underlying full-screen route is computed for the deep link, not in the placeholder styling.

[mukhrr]

Proposal

What is the root cause of that problem?

For a /search/r/<reportID> deep link the report is fetched by SearchMoneyRequestReportPage's mount effect, and only there. AuthScreensInitHandler and DeepLinkHandler are not involved, because getReportIDFromLink returns an empty string for any route other than SCREENS.REPORT:

App/src/libs/ReportUtils.ts

Lines 10220 to 10228 in 7392971

	function getReportIDFromLink(url: string | null): string {
	const route = getRouteFromLink(url);
	const {reportID, isSubReportPageRoute} = parseReportRouteParams(route);
	if (isSubReportPageRoute) {
	// We allow the Sub-Report deep link routes (settings, details, etc.) to be handled by their respective component pages
	return '';
	}
	return reportID;
	}

App/src/pages/Search/SearchMoneyRequestReportPage.tsx

Lines 191 to 224 in 7392971

	useEffect(() => {
	// Reset flag when reportID changes (screen stays mounted but navigates to different report)
	if (prevReportIDFromRoute !== reportIDFromRoute) {
	isInitialMountRef.current = true;
	}
	// Guard prevents calling openReport for multi-transaction reports
	if (visibleTransactions.length > 2 && !isInitialMountRef.current) {
	return;
	}
	if (transactionThreadReportID === CONST.FAKE_REPORT_ID && oneTransactionID) {
	const iouAction = getIOUActionForTransactionID(reportActions, oneTransactionID);
	createTransactionThreadReport({
	introSelected,
	currentUserLogin: currentUserEmail ?? '',
	currentUserAccountID,
	betas,
	iouReport: report,
	iouReportAction: iouAction,
	});
	return;
	}
	openReport({reportID: reportIDFromRoute, introSelected, betas, hasReportActions});
	isInitialMountRef.current = false;
	// oneTransactionID dependency handles the case when deleting a transaction:
	// oneTransactionID updates after transactionThreadReportID,
	// so we need it in dependencies to re-run the effect with the correct remaining transaction.
	// For more details see https://github.com/Expensify/App/pull/80107
	// We don't want this hook to re-run on the every report change
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [reportIDFromRoute, transactionThreadReportID, oneTransactionID, betas]);

On a cold boot after the transition flow, that OpenReport races the initial OpenApp. I confirmed on the wire (dev web, authenticated cold boot with an empty Onyx store) that OpenReport is enqueued first, and that the OpenApp response applies setcollection updates for report_, transactions_ and transactionViolations_ containing only the priority snapshot. A settled report I deep linked to was missing from that snapshot entirely. Both requests are WRITEs whose response data is deferred until the sequential queue drains, and that flush is documented as able to lose the earlier request's updates:

App/src/libs/Network/SequentialQueue.ts

Lines 424 to 427 in 7392971

	// The queue can be paused when we sync the data with backend so we should only update the Onyx data when the queue is empty
	if (!hasRemainingRequests) {
	Log.info('[SequentialQueue] Queue is empty, flushing Onyx updates');
	flushOnyxUpdatesQueue()?.then(() => {

App/src/libs/actions/QueuedOnyxUpdates.ts

Lines 60 to 66 in 7392971

	// WRITE requests queue their updates here and advance the lastUpdateID watermark before this deferred flush runs.
	// If the flush fails the updates are lost while the client already claims to be caught up, so surface it in Sentry.
	return Onyx.update(copyUpdates).catch((error: unknown) => {
	Log.alert('[OnyxUpdateManagerError] Deferred WRITE Onyx update failed to apply after the watermark advanced, the updates may be lost', {
	error: error instanceof Error ? error.message : String(error),
	});
	throw error;

The same race is already documented and patched, but only for anonymous public room deep links:

App/src/DeepLinkHandler.tsx

Lines 169 to 188 in 7392971

	// An anonymous user opening a public room via a cold deep link loads the room (OpenReport), but the
	// OpenApp that follows anonymous session creation drops it from Onyx, so it never reaches the LHN.
	// Once OpenApp settles, re-fetch the room if it went missing so it shows up in the LHN. See #92672.
	useEffect(() => {
	const reportID = pendingPublicRoomReportID.current;
	if (!reportID || isLoadingApp || !isAnonymousUser()) {
	return;
	}
	// The room made it into Onyx, so the cold-start race is over - stop tracking it.
	if (allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`]?.reportID) {
	pendingPublicRoomReportID.current = '';
	hasRefetchedPublicRoom.current = false;
	return;
	}
	if (hasRefetchedPublicRoom.current) {
	return;
	}
	hasRefetchedPublicRoom.current = true;
	Report.openReport({reportID, introSelected, betas});
	}, [isLoadingApp, allReports, introSelected, betas]);

The end state is a report that survives in Onyx (a report awaiting the user's approval is in the LHN priority snapshot) while its transactions do not. shouldWaitForTransactions then returns true indefinitely, since transactions.length === 0 with report.total !== 0, so MoneyRequestReportView renders the skeleton forever:

App/src/libs/MoneyRequestReportUtils.ts

Lines 145 to 163 in 7392971

	function shouldWaitForTransactions(report: OnyxEntry<Report>, transactions: Transaction[] | undefined, reportLoadingState: OnyxEntry<ReportLoadingState>, isOffline = false) {
	if (isOffline) {
	return false;
	}
	const isTransactionDataReady = transactions !== undefined;
	const isTransactionThreadView = isReportTransactionThread(report);
	// Scope the dismiss-write check to *this* report so an unrelated submit flow that's
	// mid-dismiss doesn't make every empty money-request/invoice report look like it's loading.
	const hasPendingDismissWrite = hasDeferredWriteForReport(CONST.DEFERRED_LAYOUT_WRITE_KEYS.DISMISS_MODAL, report?.reportID);
	const isStillLoadingData =
	transactions?.length === 0 &&
	((!!reportLoadingState?.isLoadingInitialReportActions && !reportLoadingState.hasOnceLoadedReportActions) || report?.total !== 0 || hasPendingDismissWrite);
	return (
	(isMoneyRequestReport(report) || isInvoiceReport(report)) &&
	(!isTransactionDataReady || isStillLoadingData) &&
	!isTransactionThreadView &&
	report?.pendingFields?.createReport !== CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD
	);

App/src/components/MoneyRequestReportView/MoneyRequestReportView.tsx

Lines 165 to 169 in 7392971

	// Prevent the empty state flash by ensuring transaction data is fully loaded before deciding which view to render
	// We need to wait for both the selector to finish AND ensure we're not in a loading state where transactions could still populate
	const shouldWaitForTransactions = shouldWaitForTransactionsUtil(report, transactions, reportLoadingState, isOffline);
	const shouldShowOpenReportLoadingSkeleton = !!(isLoadingInitialReportActions && reportActions.length === 0 && !isOffline) || shouldWaitForTransactions;

Nothing recovers from this. The mount effect's dependencies never change again (the dropped transactions were never observed by React, so oneTransactionID stays undefined), and its visibleTransactions.length > 2 guard blocks refetches for multi transaction reports. The Home page showing behind the skeleton is the HOME_TO_RHP relation doing its job for the transition entry (LogOutPreviousUserPage returns to Home and then navigates to exitTo), not part of the failure.

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

Apply the same self healing check the app already uses for anonymous public rooms, at the layer that owns this fetch. Once the initial OpenApp and OpenReport requests and their deferred updates settle, verify the report's data actually survived and refetch once if it did not. In SearchMoneyRequestReportPage:

+    const isAppLoadPending = useIsAppLoadPending();
+    const isReportLoadPending = useIsReportLoadPending(reportIDFromRoute);
+    const wasInitialLoadPendingRef = useRef(false);
+    const hasVerifiedReportDataRef = useRef(false);
+
+    useEffect(() => {
+        if (isAppLoadPending || isReportLoadPending) {
+            wasInitialLoadPendingRef.current = true;
+            return;
+        }
+        if (!wasInitialLoadPendingRef.current || hasVerifiedReportDataRef.current) {
+            return;
+        }
+        hasVerifiedReportDataRef.current = true;
+        if (report?.reportID && !shouldWaitForTransactions(report, reportTransactions, reportLoadingState, isOffline)) {
+            return;
+        }
+        openReport({reportID: reportIDFromRoute, introSelected, betas, hasReportActions});
+    }, [isAppLoadPending, isReportLoadPending, /* data deps */]);

useIsAppLoadPending and useIsReportLoadPending already cover the deferred updates window, so the check runs exactly once, after the flush that could have dropped the data. Reusing shouldWaitForTransactions for the missing data verdict makes the refetch condition exactly the skeleton condition, so a legitimately empty report (total === 0) or a transaction thread view never triggers a spurious request, and warm in app navigation is a no op. The once per mount guard prevents loops when the report is genuinely inaccessible.

I verified this red to green in the browser through the real transition flow (short lived token sign in, then exitTo=search/r/:reportID): before the fix the skeleton never resolves over Home, after the fix a single recovery OpenReport restores the report. I also added a component test that fails on the unfixed page and passes with the fix.

What alternative solutions did you explore? (Optional)

I explored delaying the page's OpenReport until OpenApp finishes. That serializes every deep link behind OpenApp's large response, slowing the common case that works today, and it still does not cover the deferred flush loss, which can drop the OpenReport data regardless of order. I also considered having OpenApp merge instead of replace the collections, but the replace is intentional for stale data cleanup, and a server contract change is riskier than a scoped client side recovery. Making the skeleton opaque or removing SEARCH_MONEY_REQUEST_REPORT from the route relations would only hide the symptom.

97159-web-before-transition.mp4

97159-web-after-transition.mp4