[$250] DEV: App Crashes When Accessing Public Room While Signed Out

[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:
Reproducible in staging?: Needs Reproduction (Unable to 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: @FitseTLT
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Sign out of the app
2. Navigate to a public room URL (e.g., https://dev.new.expensify.com:8082/r/7075912447943023)
3. Observe behavior

Expected Result:

App should Load the public room

Actual Result:

App crashes when accessing the link while signed out

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

2026-04-22.18-16-01.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mollfpr

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022047021259145934599
• Upwork Job ID: 2047021259145934599
• Last Price Increase: 2026-04-22

[MelvinBot]

Proposal

What is the root cause of that problem?

When a signed-out user navigates to a public room URL (e.g., /r/7075912447943023), the app's deep link flow calls openReport() via openReportFromDeepLink() to check if the room is public. For public rooms, the server returns an anonymous auth token, allowing the app to render AuthScreens and display the room.

However, if the OpenReport API call fails (network error, server error, non-public room), the IS_CHECKING_PUBLIC_ROOM flag is still set to false via finallyData, causing NavigationRoot to render with authenticated=false. This sends the user to PublicScreens, which only defines sign-in related screens — no REPORTS_SPLIT_NAVIGATOR or report screens.

The linking config's getAdaptedStateFromPath converts the /r/{reportID} URL into a navigation state containing REPORTS_SPLIT_NAVIGATOR. When PublicScreens receives this state, React Navigation's StackRouter.getRehydratedState filters out the unknown route and falls back to HOME (SignInPage). While this fallback is normally graceful, recent navigation changes — particularly PR #87089 (dynamic route state construction, merged 2026-04-22) and PR #87768 (dismiss-first navigation fast paths, merged 2026-04-21) — may have introduced a crash during this state reconciliation when the navigator tree doesn't match the URL-derived state.

Additionally, the waitForUserSignIn() promise chain in Link.ts:281 never resolves for unauthenticated users who don't receive an anonymous token, meaning the deferred deep link navigation logic hangs indefinitely without cleanup.

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

1. Add error handling for the public room check failure path: In openReportFromDeepLink(), when the OpenReport API call fails (no anonymous token returned), the app should gracefully redirect to the sign-in page with the deep link URL preserved, so the user can sign in and then be navigated to the report.

2. Guard getAdaptedStateFromPath for unauthenticated context: The linking config should detect when PublicScreens is active (unauthenticated) and avoid producing navigation states with screens that only exist in AuthScreens. This would prevent the state mismatch that causes the crash during reconciliation.

3. Review interaction with PR Build full navigation state for stacked dynamic routes on refresh #87089's getDynamicRouteAdaptedState: The new dynamic route adaptation logic at getDynamicRouteAdaptedState.ts should handle the case where the focused route is a report screen but no AuthScreens navigator is mounted.

What alternative solutions did you explore? (Optional)

An alternative would be to always issue an anonymous auth token for deep link report URLs (even for non-public rooms) and then show a "not found" or "access denied" screen within AuthScreens. This avoids the PublicScreens state mismatch entirely but changes the auth flow semantics.

Investigation details

Flow traced:

1. User opens /r/{reportID} → app loads → IS_CHECKING_PUBLIC_ROOM defaults to true (blocks NavigationRoot)
2. DeepLinkHandler calls openReportFromDeepLink() → calls openReport({reportID, isFromDeepLink: true})
3. Success (public room): Server returns anonymous token → isAuthenticated=true → AuthScreens renders → works
4. Failure: No token → IS_CHECKING_PUBLIC_ROOM=false → NavigationRoot renders with authenticated=false → PublicScreens renders → state mismatch

Key files:

• src/Expensify.tsx:60,281-288 — gates NavigationRoot on IS_CHECKING_PUBLIC_ROOM
• src/DeepLinkHandler.tsx:43-59 — processes initial URL
• src/libs/actions/Link.ts:235-254 — openReportFromDeepLink public room check
• src/libs/Navigation/AppNavigator/AppNavigator.tsx:12-27 — binary auth routing
• src/libs/Navigation/AppNavigator/PublicScreens.tsx — no report screens defined
• src/libs/Navigation/helpers/getAdaptedStateFromPath.ts:359-378 — URL-to-state conversion

Recent changes that may be contributing (all merged 2026-04-22):

• PR Remove Onyx.connect() for the key: ONYXKEYS.STASHED_SESSION #87985: Refactored stashed session handling in Session/index.ts
• PR Build full navigation state for stacked dynamic routes on refresh #87089: Changed navigation state construction for dynamic routes on refresh
• PR fix: prevent Concierge redirect and LHN disappearance when vacation delegate splits expense #86869: Modified ReportFetchHandler for Concierge redirect

Confidence: Medium — Code analysis identifies the state mismatch as the most likely crash vector, but without a stack trace or Sentry crash data, the exact exception cannot be confirmed. The recently merged navigation PRs are strong candidates for introducing the crash.

---

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.

[wildan-m]

Proposal

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

When a user signs out and then opens a public room deep link such as /r/<reportID>, the web app is stuck forever on the green boot splash instead of loading the public room. From the user's perspective the app is hung/crashed.

What is the root cause of that problem?

DeepLinkHandler subscribes to several Onyx values with useOnyx and lists the raw values introSelected, isSelfTourViewedMetadata, and betas in its useEffect dependency array:

App/src/DeepLinkHandler.tsx

Lines 30 to 77 in 9941398

	const [allReports] = useOnyx(ONYXKEYS.COLLECTION.REPORT);
	const [, sessionMetadata] = useOnyx(ONYXKEYS.SESSION);
	const [conciergeReportID] = useOnyx(ONYXKEYS.CONCIERGE_REPORT_ID);
	const [introSelected] = useOnyx(ONYXKEYS.NVP_INTRO_SELECTED);
	const [isSelfTourViewed, isSelfTourViewedMetadata] = useOnyx(ONYXKEYS.NVP_ONBOARDING, {selector: hasSeenTourSelector});
	const [betas] = useOnyx(ONYXKEYS.BETAS);
	const isAuthenticated = useIsAuthenticated();
	useEffect(() => {
	if (isLoadingOnyxValue(sessionMetadata, isSelfTourViewedMetadata)) {
	return;
	}
	// If the app is opened from a deep link, get the reportID (if exists) from the deep link and navigate to the chat report
	Linking.getInitialURL().then((url) => {
	onInitialUrl(url as Route);
	if (url) {
	if (conciergeReportID === undefined) {
	Log.info('[Deep link] conciergeReportID is undefined when processing initial URL', false, {url});
	}
	if (introSelected === undefined) {
	Log.info('[Deep link] introSelected is undefined when processing initial URL', false, {url});
	}
	openReportFromDeepLink(url, allReports, isAuthenticated, conciergeReportID, introSelected, isSelfTourViewed, betas);
	} else {
	Report.doneCheckingPublicRoom();
	}
	endSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.DEEP_LINK);
	});
	// Open chat report from a deep link (only mobile native)
	linkingChangeListener.current = Linking.addEventListener('url', (state) => {
	if (conciergeReportID === undefined) {
	Log.info('[Deep link] conciergeReportID is undefined when processing URL change', false, {url: state.url});
	}
	if (introSelected === undefined) {
	Log.info('[Deep link] introSelected is undefined when processing URL change', false, {url: state.url});
	}
	const isCurrentlyAuthenticated = hasAuthToken();
	openReportFromDeepLink(state.url, allReports, isCurrentlyAuthenticated, conciergeReportID, introSelected, isSelfTourViewed, betas);
	});
	return () => {
	linkingChangeListener.current?.remove();
	};
	// eslint-disable-next-line react-hooks/exhaustive-deps -- intentionally excluding allReports, isAuthenticated, and onInitialUrl to avoid re-triggering deep link handling on every report update
	}, [sessionMetadata?.status, conciergeReportID, introSelected, isSelfTourViewedMetadata, betas]);

These three are non-primitive (object / metadata object / array), so React compares them by reference. Every Onyx merge into NVP_INTRO_SELECTED, NVP_ONBOARDING, or BETAS produces a new reference and re-fires the effect.

On a cold load of /r/<reportID> while signed out, the effect calls openReportFromDeepLink, which for the unauthenticated + reportID branch fires openReport({reportID, isFromDeepLink: true, ...}):

App/src/libs/actions/Link.ts

Lines 232 to 254 in 9941398

	) {
	const reportID = getReportIDFromLink(url);
	if (reportID && !isAuthenticated) {
	// Start span for public room API call
	startSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.PUBLIC_ROOM_API, {
	name: CONST.TELEMETRY.SPAN_BOOTSPLASH.PUBLIC_ROOM_API,
	op: CONST.TELEMETRY.SPAN_BOOTSPLASH.PUBLIC_ROOM_API,
	parentSpan: getSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.PUBLIC_ROOM_CHECK),
	});
	// Call the OpenReport command to check in the server if it's a public room. If so, we'll open it as an anonymous user
	openReport({reportID, introSelected, parentReportActionID: '0', isFromDeepLink: true, betas});
	// Show the sign-in page if the app is offline
	if (getIsOffline()) {
	endSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.PUBLIC_ROOM_API);
	doneCheckingPublicRoom();
	}
	} else {
	// If we're not opening a public room (no reportID) or the user is authenticated, we unblock the UI (hide splash screen)
	doneCheckingPublicRoom();
	}

The backend responds with onyxData that writes into BETAS and the onboarding keys. Those writes mutate the references that the effect depends on, so the effect immediately re-fires, calls openReportFromDeepLink again, which fires openReport again — and the response mutates the same keys again. The observable symptom in the console is the exact signature of the bug: one long in-flight OpenReport followed by a burst of one-per-second duplicate OpenReport calls, all jsonCode 200:

[Network] Finished API request in 23179ms - OpenReport jsonCode:200
[Network] Finished API request in 3974ms  - OpenReport jsonCode:200
[Network] Finished API request in 1094ms  - OpenReport jsonCode:200
[Network] Finished API request in 1036ms  - OpenReport jsonCode:200
...

Independently, the boot-splash gate shouldInit = isNavigationReady && hasAttemptedToOpenPublicRoom && !!preferredLocale never latches:

App/src/Expensify.tsx

Lines 136 to 156 in 9941398

	const isSplashReadyToBeHidden = splashScreenState === CONST.BOOT_SPLASH_STATE.READY_TO_BE_HIDDEN;
	const isSplashVisible = splashScreenState === CONST.BOOT_SPLASH_STATE.VISIBLE;
	const shouldInit = isNavigationReady && hasAttemptedToOpenPublicRoom && !!preferredLocale;
	const shouldHideSplash = shouldInit && (CONFIG.IS_HYBRID_APP ? isSplashReadyToBeHidden : isSplashVisible);
	// We store this in a ref to get the latest values in BootsplashMonitor callback
	const gateStatusRef = useRef<BootsplashGateStatus | null>(null);
	gateStatusRef.current = {
	splashScreenState,
	isOnyxMigrated,
	isCheckingPublicRoom,
	hasAttemptedToOpenPublicRoom,
	isNavigationReady,
	preferredLocale,
	shouldInit,
	shouldHideSplash,
	isAuthenticated,
	updateRequired,
	lastVisitedPath,
	};

hasAttemptedToOpenPublicRoom is set once isCheckingPublicRoom becomes false, but because Onyx.clear() at sign-out removed the key and useOnyx(IS_CHECKING_PUBLIC_ROOM, {initWithStoredValues: false}) re-defaults it to true, and because the effect keeps re-queuing OpenReport, the splash never transitions to hidden.

The regression was introduced on 2026-03-13 by commit 86cee27c161 ("add betas to deps."), which added betas to the dep list. betas is a refreshed array in every OpenReport response, so it is the reliable loop trigger; introSelected and isSelfTourViewedMetadata were already unstable for the same reason but happened not to mutate on the old path.

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

The dep array should be keyed off loading status, not off the values themselves, because the intent of those entries is purely "wait until Onyx has hydrated these keys". We already do this correctly for sessionMetadata?.status — extend the same pattern to the other three.

Read the metadata alongside the value for the three keys that currently leak into deps, and depend on the .status string primitive of each instead of the value:

• Change const [introSelected] = useOnyx(ONYXKEYS.NVP_INTRO_SELECTED) to also destructure the metadata.
• isSelfTourViewedMetadata is already destructured — put isSelfTourViewedMetadata?.status in the dep list in place of the whole metadata object.
• Change const [betas] = useOnyx(ONYXKEYS.BETAS) to also destructure the metadata.
• Rewrite the dep list to [sessionMetadata?.status, conciergeReportID, introSelectedMetadata?.status, isSelfTourViewedMetadata?.status, betasMetadata?.status].

Status flips once from loading to loaded and then stays stable, so the effect fires exactly once per mount after hydration — which is the documented intent of the existing // eslint-disable-next-line react-hooks/exhaustive-deps comment. The values themselves are still read inside the effect body and passed to openReportFromDeepLink, so no caller signature changes and no behavior changes for legitimate new mounts.

This breaks the infinite loop because BETAS merges from the OpenReport response no longer touch betasMetadata.status (it stays 'loaded'), so the effect does not re-fire, openReport runs exactly once, its finallyData sets IS_CHECKING_PUBLIC_ROOM=false, the splash gate latches, and the public room renders normally.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88545-fix-deep-link-infinite-loop?expand=1

What alternative solutions did you explore? (Optional)

• Revert 86cee27c161 (remove betas from deps). Reduces loop frequency in practice but does not fix the root cause: introSelected and isSelfTourViewedMetadata are still non-primitive deps, and any backend payload that merges into NVP_INTRO_SELECTED or NVP_ONBOARDING on the unauth path would reintroduce the loop. Rejected as a fix for the wrong layer.
• Guard openReportFromDeepLink against re-entry when a prior OpenReport for the same reportID is in flight. Treats the symptom (duplicate requests to the server) without preventing the React render churn, and would have to carry its own "in-flight" state alongside IS_CHECKING_PUBLIC_ROOM. Rejected as strictly worse than fixing the dep list.
• Move betas/introSelected/isSelfTourViewed reads into refs updated by a separate effect. Works, but adds two extra hooks, makes the eslint-disable comment harder to audit, and diverges from the pattern already used for sessionMetadata?.status in the same file.

[melvin-bot]

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

[melvin-bot]

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

[ReaperOAK]

Proposal

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

When a signed‑out user opens a public room deep link (e.g. /r/7075912447943023), the app never leaves the boot splash and appears crashed/hung. In the network log this manifests as a long‑running OpenReport followed by a burst of ~1/sec duplicate OpenReport requests (all jsonCode: 200) that never stops.

What is the root cause of that problem?

This is not a navigator/PublicScreens crash — it is a self‑feeding useEffect loop in src/DeepLinkHandler.tsx that never lets the boot‑splash gate latch.

1. DeepLinkHandler subscribes to several Onyx values and lists non‑primitive values directly in its useEffect dependency array:

   src/DeepLinkHandler.tsx#L30-L77

   const [introSelected] = useOnyx(ONYXKEYS.NVP_INTRO_SELECTED);
   const [isSelfTourViewed, isSelfTourViewedMetadata] = useOnyx(ONYXKEYS.NVP_ONBOARDING, {selector: hasSeenTourSelector});
   const [betas] = useOnyx(ONYXKEYS.BETAS);
   ...
   }, [sessionMetadata?.status, conciergeReportID, introSelected, isSelfTourViewedMetadata, betas]);

   introSelected is an object, betas is an array, and isSelfTourViewedMetadata is a metadata object. React compares deps by reference, so any Onyx merge into NVP_INTRO_SELECTED, NVP_ONBOARDING, or BETAS produces a new reference and re‑fires the effect.

2. On a cold load of /r/<reportID> while signed out, the effect calls openReportFromDeepLink, which for the reportID && !isAuthenticated branch fires openReport({reportID, isFromDeepLink: true, betas, introSelected, ...}) (src/libs/actions/Link.ts#L235-L244).

3. The OpenReport response ships onyxData that merges into BETAS, NVP_INTRO_SELECTED and NVP_ONBOARDING. Those merges mutate the references the effect depends on, so the effect immediately re‑fires → calls openReportFromDeepLink → fires openReport again → response mutates the same keys again → forever. This is exactly the "one long request followed by 1/sec duplicates" signature in the logs.

4. The boot‑splash gate never latches:

   src/Expensify.tsx#L139

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

   hasAttemptedToOpenPublicRoom only flips once isCheckingPublicRoom is observed false. Each re‑fire calls openReport({isFromDeepLink: true}), whose finallyData resets IS_CHECKING_PUBLIC_ROOM=false only after the in‑flight request resolves (Report/index.ts#L1632-L1638). Because a new OpenReport is queued before the prior one resolves — and useOnyx(IS_CHECKING_PUBLIC_ROOM, {initWithStoredValues: false}) re‑defaults to true after Onyx.clear() at sign‑out — the gate oscillates and the splash never hides. Result: green splash forever, user perceives a crash.

5. The regression was introduced by commit 86cee27c161 ("add betas to deps"), which added betas to the dep list. betas is re‑written on every OpenReport response for unauthenticated users, so it is the reliable loop trigger. introSelected and isSelfTourViewedMetadata were already reference‑unstable for the same reason but happened not to be mutated on the unauth path before; any future payload that merges into those keys would reintroduce the loop even if betas were removed.

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

The dep array's documented intent (per the existing // eslint-disable-next-line react-hooks/exhaustive-deps comment) is simply "wait until Onyx has hydrated these keys, then fire once" — not "re‑fire on every value change". The file already does this correctly for sessionMetadata?.status. Extend the same pattern to the other three entries by depending on the hydration status primitives of each Onyx subscription.

File: src/DeepLinkHandler.tsx

1. Destructure metadata for the two entries that don't currently expose it:

   - const [introSelected] = useOnyx(ONYXKEYS.NVP_INTRO_SELECTED);
   + const [introSelected, introSelectedMetadata] = useOnyx(ONYXKEYS.NVP_INTRO_SELECTED);
     const [isSelfTourViewed, isSelfTourViewedMetadata] = useOnyx(ONYXKEYS.NVP_ONBOARDING, {selector: hasSeenTourSelector});
   - const [betas] = useOnyx(ONYXKEYS.BETAS);
   + const [betas, betasMetadata] = useOnyx(ONYXKEYS.BETAS);

2. Replace the non‑primitive deps with their .status strings (which flip loading → loaded exactly once per mount):

   - }, [sessionMetadata?.status, conciergeReportID, introSelected, isSelfTourViewedMetadata, betas]);
   + }, [sessionMetadata?.status, conciergeReportID, introSelectedMetadata?.status, isSelfTourViewedMetadata?.status, betasMetadata?.status]);

3. Strengthen the hydration gate at the top of the effect so we only proceed once all required keys are hydrated (fixes a latent race where introSelected/betas were consumed before load):

   - if (isLoadingOnyxValue(sessionMetadata, isSelfTourViewedMetadata)) {
   + if (isLoadingOnyxValue(sessionMetadata, introSelectedMetadata, isSelfTourViewedMetadata, betasMetadata)) {
         return;
     }

4. Update the stale eslint-disable comment so future readers understand why raw values are deliberately absent from deps:

   - // eslint-disable-next-line react-hooks/exhaustive-deps -- intentionally excluding allReports, isAuthenticated, and onInitialUrl to avoid re-triggering deep link handling on every report update
   + // eslint-disable-next-line react-hooks/exhaustive-deps -- we depend on the hydration status of each Onyx key, not the values themselves, so that the effect fires exactly once per mount after hydration. Including the values would loop because `OpenReport`'s onyxData merges back into BETAS / NVP_INTRO_SELECTED / NVP_ONBOARDING.

Why this works: metadata.status is a stable string ('loading' | 'loaded') that flips exactly once and then stays constant. Every subsequent Onyx.merge into those keys — including the ones in OpenReport's onyxData — leaves status === 'loaded' unchanged, so the effect is not re‑invoked. The values themselves are still read inside the effect body via closure and passed to openReportFromDeepLink, so the caller signature and payload are unchanged. No behavior change for legitimate cold mounts; no caller site needs to change.

Verification steps after patch:

• Sign out, open https://dev.new.expensify.com:8082/r/<reportID> → splash hides, public room renders.
• DevTools Network: exactly one OpenReport request (not a 1/sec burst).
• Add a console log inside the effect body; verify it prints once per navigation, not continuously.

What alternative solutions did you explore? (Optional)

• Revert 86cee27c161 (remove betas from deps). Masks the symptom today because betas is the loudest trigger on the unauth path, but introSelected and isSelfTourViewedMetadata are still reference‑unstable non‑primitives. Any future backend payload that merges into NVP_INTRO_SELECTED or NVP_ONBOARDING on the unauth path reintroduces the exact same loop. Rejected: fixes the wrong layer.

• Add a re‑entry guard inside openReportFromDeepLink (in‑flight flag keyed on reportID). Would stop the duplicate OpenReport network calls but does not stop the React render churn from the runaway effect, and it introduces a second piece of state alongside IS_CHECKING_PUBLIC_ROOM that has to be reset on every edge case (offline, sign‑in, sign‑out, navigation back). Useful as defence‑in‑depth on top of the real fix, but unacceptable as the primary fix.

• Move betas / introSelected / isSelfTourViewed reads into refs updated by a separate effect. Technically works but adds two extra hooks, makes the eslint-disable audit harder, and diverges from the sessionMetadata?.status pattern already established in the same file for the same purpose.

• Guard PublicScreens / getAdaptedStateFromPath for unauth navigator mismatch (the "navigator crash" theory). Investigated and ruled out: StackRouter.getRehydratedState already falls back gracefully to HOME (SignInPage) when it encounters an unknown route, which is why no red‑screen / native crash is observable — the splash simply never hides. Chasing a navigator fix here would add defensive code for a symptom rather than the actual cause.

[wildan-m]

Proposal updated — added compare branch with implementation.

[github-actions]

⚠️ @ReaperOAK Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[twilight2294]

Proposal

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

When a signed-out user opens a public room deep link, the app gets stuck on the green splash screen indefinitely instead of displaying the room.

What is the root cause of that problem?

The IS_CHECKING_PUBLIC_ROOM flag is set to false via finallyData inside openReport() in Report, but that finallyData is never applied. On a fresh app load, lastUpdateIDFromClient is 0 (falsy), so doesClientNeedToBeUpdated in OnyxUpdates returns true. This causes SaveResponseInOnyx to defer the response instead of applying it. The OnyxUpdateManager then performs a full reconnect and explicitly discards the deferred update — including the finallyData that would have set IS_CHECKING_PUBLIC_ROOM = false. Since this flag stays true, Expensify.tsx never renders NavigationRoot and the splash screen hangs forever.

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

In openReportFromDeepLink in Link, call doneCheckingPublicRoom() unconditionally after openReport() — not just when offline:

openReport({reportID, introSelected, parentReportActionID: '0', isFromDeepLink: true, betas});
endSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.PUBLIC_ROOM_API);
doneCheckingPublicRoom();

And remove the now-redundant IS_CHECKING_PUBLIC_ROOM entry from finallyData in Report, since relying on finallyData for this flag is unreliable when the response can be deferred and discarded by the OnyxUpdateManager.

What alternative solutions did you explore? (Optional)

MelvinBot's proposal attributes the crash to a navigation state mismatch when the OpenReport API fails, but the bug reproduces with successful 200 responses — the issue is that successful responses are deferred by gap detection, not that they fail. wildan-m's proposal correctly identifies an infinite-loop issue in DeepLinkHandler's dependency array, but even fixing the loop doesn't help if a single openReport call has its finallyData silently discarded. This proposal targets the fundamental reason IS_CHECKING_PUBLIC_ROOM never flips: finallyData is an unreliable mechanism for critical app-boot flags when the OnyxUpdateManager can discard entire responses. Moving the flag-flip to the call site makes it independent of response handling.