[$250] chat-Tapping invalid deeplink directs to hmm not here briefly & not directs frm self dm

[applause-bot]

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: V9.4.35-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-3370/folder/13176964/41237741/1145199356?sort=%2Bidentifier
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Chat Report View

Action Performed:

1. Launch app
2. Open workspace chat
3. Send a message
4. Copy link of that message & send it in the chat
5. Delete the message sent in step 3
6. Tap on the link
7. Note hmm not here briefly shown
8. Open self dm and send the same link
9. Open the link
10. Note user directed to workspace chat
11. Tap on link in workspace chat again few times
12. Note only after tapping few times , user directed once to hmm not here briefly

Expected Result:

Tapping invalid deeplink must direct to hmm not here.

Actual Result:

Tapping invalid deeplink directs to hmm not here briefly & not directs to hmm not here when opening link from self dm.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7209795_1784204678821.Screenrecorder-2026-07-16-17-45-31-185.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7209795

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077754300497246971
• Upwork Job ID: 2077754300497246971
• Last Price Increase: 2026-07-16

Issue Owner

Current Issue Owner: @yusufdeveloper2903

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/fa5485b93b4710d0ca33a270f72941000d696f9af99afd29fd43f8a2eda437ea

[MelvinBot]

Proposal

What is the root cause of that problem?

Both symptoms trace to the same place: LinkedActionNotFoundGuard deliberately auto-recovers from a deleted linked message by stripping the reportActionID route param via useAutoNavigateForDeletedLinkedAction. Once the param is gone, the guard stops rendering "Hmm... it's not here" and shows the report instead.

Whether you see the not-found page depends on a timing race, which is why the two entry points behave differently:

• Tapping the link inside the same workspace chat — the report actions are already loaded, so shouldShowNotFoundLinkedAction evaluates true for one render → not-found paints for a frame → the useLayoutEffect strips reportActionID → report re-appears. That is the brief flash. It only lands "on some taps" because the loading-cycle gate (hasSeenLoadingCycle / isLoadingInitialReportActions) has to line up just right for that one render.
• Tapping the link from Self DM — openLink routes to a different report, so openReport runs and isLoadingInitialReportActions stays true during load. The anti-flash gate holds not-found off during loading, and by the time loading finishes the auto-navigate has already cleared reportActionID — so not-found never renders and you land directly on the workspace chat.

So the deeper problem is that the same invalid deep link produces two different outcomes depending on where it was tapped, and neither matches the reporter's expectation of a stable "not here" page.

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

This needs a product decision on the intended behavior for a deep link to a deleted message, then make both entry points consistent:

• If the not-found page should stay (matches the reporter's expected result): stop auto-navigating away in the deleted case — gate the useAutoNavigateForDeletedLinkedAction call so it only recovers when the action was never present (a stale/absent link), not when isLinkedActionDeleted is true. Then both the same-chat tap and the Self-DM tap land on a stable "Hmm... it's not here".
• If auto-recovery to the report is intended (don't dead-end the user): keep the recovery but suppress the one-frame not-found render so it never flashes, and make the same-chat path recover the same way the Self-DM path already does — i.e. no visible "not here" at all in either case.

Either way the fix is to converge the two paths on one behavior. Recommend confirming with the team which of the two is the intended UX before implementing.

What alternative solutions did you explore? (Optional)

Confirming with a client log would nail the exact per-tap ordering — the guard already emits Log.info('[ReportScreen] Displaying NotFound Page for linked action', ...) at LinkedActionNotFoundGuard.tsx:121-134 with isLoadingInitialReportActions, hasSeenLoadingCycle, wasEverVisible, and linkedActionExists, so the branch taken on each tap is observable.

Investigation details & confidence

Confidence: Medium-High. High on the mechanism (the auto-navigate hook stripping reportActionID is what both dismisses the flash and skips not-found from Self DM). Medium on the precise per-tap loading race, which is timing-dependent and best confirmed with the log line above.

Evidence chain:

• The not-found gate: LinkedActionNotFoundGuard.tsx:117-118 — shouldShowNotFoundLinkedAction requires !wasEverVisible and either isLinkedActionDeleted or a completed loading cycle with no linked action.
• The flash mechanism: useAutoNavigateForDeletedLinkedAction.ts:10-19 runs in a useLayoutEffect and calls navigateToEndOfReport → Navigation.setParams({reportActionID: undefined}).
• The entry-point fork: Link.ts:346-386 — getReportLinkRoute returns the plain report route (with reportActionID) when the link is tapped from the same focused report, but a SEARCH_REPORT RHP route when tapped from a different report (the Self DM).

Alternative explanation considered: if the linked report is a money-request/expense report, getReportLinkRoute can route to an expense-report RHP with no reportActionID at all, which would bypass the guard entirely. For a plain workspace-chat message (this issue) the reportActionID-bearing paths above apply.

---

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

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 14:06:15 UTC.

Proposal

What is the root cause of that problem?

Opening a deep link to a deleted message is meant to drop the now-invalid reportActionID and open the report at its end — that auto-recovery was added on purpose in #82508 ("display report once user accesses invalid reportActionID"). The defect is that the recovery lands one commit too late, so "Hmm… it's not here" paints for a frame first, and whether it paints at all depends on where the link was tapped — that is the inconsistency the tester hit.

A deleted comment is not removed from Onyx, only hidden, so in LinkedActionNotFoundGate the linked action is found, isReportActionVisible returns false, and isLinkedActionDeleted → shouldShowNotFoundLinkedAction is true on the gate's very first render:

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 117 to 118 in d1835ca

	const shouldShowNotFoundLinkedAction =
	!wasEverVisible && !isLinkedActionInaccessibleWhisper && (isLinkedActionDeleted || (hasSeenLoadingCycle && !isLoadingInitialReportActions && !linkedAction));

That one flag does two opposite things in the same render: it renders <FullPageNotFoundView shouldShow> (L192-206) and it feeds useAutoNavigateForDeletedLinkedAction, whose useLayoutEffect clears the reportActionID param:

App/src/pages/inbox/hooks/useAutoNavigateForDeletedLinkedAction.ts

Lines 10 to 19 in d1835ca

	function useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction: boolean, navigateToEndOfReport: () => void) {
	useLayoutEffect(() => {
	if (!shouldShowNotFoundLinkedAction) {
	return;
	}
	navigateToEndOfReport();
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [shouldShowNotFoundLinkedAction]);
	}

So the not-found page is mounted and then torn down a commit later. On Android NativeStackView commits the mounted view before the layout effect runs — the file already documents this exact hazard for the sibling wasEverVisible path at L106-113 — so the page flashes. Whether it is visible is pure paint timing: from the self-DM the param is cleared during the push transition before anything paints, so no page shows and the user lands straight in the workspace chat (steps 8-10); re-tapping inside the chat only sometimes lines the two commits up within one frame (steps 11-12).

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

Make the recovery atomic so the not-found page is never committed to the native view tree for a linked action we are about to auto-recover from. Set the recovery flag during render — the same React pattern the file already uses for wasEverVisible/hasSeenLoadingCycle — which forces a synchronous re-render before the commit, so FullPageNotFoundView never reaches Android's view hierarchy and there is no frame to flash:

const [isRecoveringLinkedAction, setIsRecoveringLinkedAction] = useState(false);
if (shouldShowNotFoundLinkedAction && !isRecoveringLinkedAction) {
    setIsRecoveringLinkedAction(true);
}

Then gate the view on it, keeping the existing hook that clears the param:

<FullPageNotFoundView shouldShow={shouldShowNotFoundLinkedAction && !isRecoveringLinkedAction} ...>

Now both entry points behave identically: a deleted-message link deterministically clears reportActionID and lands on the report end, with no not-found flash and no self-DM vs workspace-chat divergence, because the outcome is decided from Onyx state instead of a commit-vs-effect race. The wasEverVisible cleanup effect and the whisper effect are untouched.

What alternative solutions did you explore? (Optional)

If product instead wants an invalid/deleted deep link to stay on "Hmm… it's not here" (the tester's literal expected result), the fix is the opposite one-liner — stop auto-recovering for the deleted case by passing shouldShowNotFoundLinkedAction && !isLinkedActionDeleted to useAutoNavigateForDeletedLinkedAction, so the page persists (with its existing "Go to chat instead" link) while genuinely non-existent action IDs still auto-open the report as #82508 intended. The two directions differ only in whether we end on the report or the not-found page, so it is worth confirming the desired end state first.

Adding a delay/opacity guard before showing the page was rejected as timing-fragile — it still races the synchronous native commit.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 14:00:06 UTC.

Proposal

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

Tapping a deeplink to a deleted message (/r/:reportID/:reportActionID) should land on the "Hmm... it's not here" (comment not found) view and stay there. Instead, when the link is tapped inside the workspace chat the not-found view only flashes for a moment before the user is bounced back to the chat, and when the same link is opened from the self DM the not-found view never appears at all — the user is silently dropped into the workspace chat.

What is the root cause of that problem?

Both symptom variants come from the same mechanism, and the difference between them is purely paint timing. When a comment is deleted, deleteReportComment in src/libs/actions/Report/index.ts doesn't remove the action from Onyx — it merges a deleted marker (message: [{html: '', text: '', ...}], lines 3036–3054), and shouldReportActionBeVisible in src/libs/ReportActionsUtils.ts (line 1318) then filters it out via !isDeletedAction(reportAction). So when the deeplink opens, LinkedActionNotFoundGate in src/pages/inbox/LinkedActionNotFoundGuard.tsx finds the linkedAction in Onyx, isReportActionVisible returns false, isLinkedActionDeleted becomes true, and shouldShowNotFoundLinkedAction is true on the very first render of the gate (the gate remounts per key={reportActionIDFromRoute}, so wasEverVisible is false):

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 117 to 118 in d1835ca

	const shouldShowNotFoundLinkedAction =
	!wasEverVisible && !isLinkedActionInaccessibleWhisper && (isLinkedActionDeleted || (hasSeenLoadingCycle && !isLoadingInitialReportActions && !linkedAction));

The gate renders FullPageNotFoundView with shouldShow=true — but in the very same commit it also runs useAutoNavigateForDeletedLinkedAction (added by PR #82508 for issue #79163, "Handle more gracefully when reportAction deep-link is incorrect"), whose useLayoutEffect immediately calls navigateToEndOfReport(), which does Navigation.setParams({reportActionID: undefined}, ...). Clearing the param unmounts the gate and the report renders normally:

App/src/pages/inbox/hooks/useAutoNavigateForDeletedLinkedAction.ts

Lines 12 to 16 in d1835ca

	if (!shouldShowNotFoundLinkedAction) {
	return;
	}
	navigateToEndOfReport();

So the not-found state is always created and then always self-destructed one commit later — whether the user sees it depends on whether the native UI presents the first commit before the second one lands. Tapping the link inside the workspace chat only updates params on the already-visible screen, so Fabric commits the not-found frame to a screen the user is looking at and the flash is visible (steps 6–7); whether it's perceptible depends on whether both commits land within one frame, which is why step 11–12 only reproduces intermittently. Opening the link from the self DM pushes a new ReportScreen, and the layout effect clears the param while the screen is still behind the push transition, so the user lands directly in the chat with no feedback at all (steps 9–10). The file's own comment (lines 110–113) acknowledges this exact native race ("NativeStackView commits UI synchronously before the effect can fire") for the wasEverVisible path, but the auto-navigate path was never gated the same way. Notably, the not-found view is designed as a real destination — it renders an explicit "Go to chat instead" escape link wired to navigateToEndOfReport (lines 198–201) — which the auto-navigate hook makes unreachable.

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

The condition currently feeding both the not-found view and the auto-navigate hook conflates two different situations: an action that exists in Onyx but is deleted/hidden (isLinkedActionDeleted, this issue's repro — a real comment the user was linked to that got deleted) and an action that simply never existed in the collection after loading (!linkedAction, the malformed-ID case that #79163 was actually about, per its QA steps of appending a garbage /123456789). These are mutually exclusive since isLinkedActionDeleted requires !!linkedAction. The fix is to split them in LinkedActionNotFoundGate: keep the persistent not-found view for the deleted case, and keep the silent auto-recovery only for the missing case, no longer rendering not-found for it:

const isLinkedActionMissing = hasSeenLoadingCycle && !isLoadingInitialReportActions && !linkedAction;
const shouldShowNotFoundLinkedAction = !wasEverVisible && !isLinkedActionInaccessibleWhisper && isLinkedActionDeleted;
// ...
useAutoNavigateForDeletedLinkedAction(!wasEverVisible && !isLinkedActionInaccessibleWhisper && isLinkedActionMissing, navigateToEndOfReport);

With this, a deeplink to a deleted comment deterministically shows and keeps the "Hmm... it's not here" view on every platform and from every origin (workspace chat and self DM behave identically, because the decision is now pure Onyx state instead of a paint race), matching the expected result, and the user recovers via the existing "Go to chat instead" link or the back button. The #79163 behavior is preserved for genuinely invalid action IDs — and actually improved, since that branch no longer renders the not-found frame before auto-recovering, eliminating the same Android flash there too. The change is safe for the other paths in the gate: the hook itself is untouched (its unit tests in tests/unit/useAutoNavigateForDeletedLinkedAction.test.ts still hold), the inaccessible-whisper effect still clears the param separately, and the wasEverVisible cleanup effect (lines 150–164) still quietly navigates away when a message is deleted while the user is already viewing it.

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 188 to 190 in d1835ca

	// this action.
	const goBack = () => (canGoBack() ? Navigation.goBack() : Navigation.goBack(ROUTES.REPORT_WITH_ID.getRoute(reportIDFromRoute)));
	useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction, navigateToEndOfReport);

What alternative solutions did you explore? (Optional)

We considered keeping the auto-navigate behavior for all invalid links and only suppressing the flash by not rendering FullPageNotFoundView whenever the hook is about to fire, which would make both repro paths consistently land in the chat with no not-found at all — but that contradicts this issue's expected result and gives the user zero feedback that the linked comment is gone. We also considered fully reverting the hook (PR #82508), but that would regress #79163 by dead-ending users on the not-found page for malformed action IDs where showing the report is clearly the better experience.

[aswin-s]

Proposal

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

On Android, tapping a deep-link to a deleted message does not reliably show the "Hmm... it's not here" page — from a self-DM it silently redirects to the workspace chat, and from the workspace chat it only flashes the not-found page briefly before redirecting. The expected behavior is that tapping an invalid/deleted-message deeplink should land on and stay on the "Hmm... it's not here" page.

What is the root cause of that problem?

useAutoNavigateForDeletedLinkedAction (src/pages/inbox/hooks/useAutoNavigateForDeletedLinkedAction.ts:10-19) unconditionally strips the reportActionID param via navigateToEndOfReport() in a useLayoutEffect the moment shouldShowNotFoundLinkedAction becomes true. That flag is produced by LinkedActionNotFoundGuard at src/pages/inbox/LinkedActionNotFoundGuard.tsx:117-118 and drives the FullPageNotFoundView at line 192-206. Because the layout effect fires synchronously after commit, the not-found view is unmounted before (self-DM case) or immediately after (workspace-chat case, hence the brief flash) it becomes visible, and the user is redirected to the end of the parent report instead of staying on the "Hmm... it's not here" screen the design calls for.

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

1. Remove the auto-redirect for the initial-deep-link case: in src/pages/inbox/LinkedActionNotFoundGuard.tsx:190 only pass useAutoNavigateForDeletedLinkedAction when the linked action disappeared after it was visible (i.e. gate the hook on wasEverVisible), so first-time deep links to a deleted action render the FullPageNotFoundView instead of being silently redirected.
2. Alternatively, delete the call at src/pages/inbox/LinkedActionNotFoundGuard.tsx:190 entirely — the sibling useEffect at lines 150-164 already handles the "action disappeared while viewing" cleanup via Navigation.setParams, so the auto-navigate hook is only reachable on fresh deep links, which is exactly the case the issue says must show "Hmm... it's not here".
3. Update the JSDoc in src/pages/inbox/hooks/useAutoNavigateForDeletedLinkedAction.ts:3-9 (or remove the file if unused after step 2) so future readers know deep-linked-to-a-deleted-action must land on the not-found page, not auto-recover.
4. Verify on Android that both flows in the repro (workspace chat re-tap and self-DM tap) now consistently show the "Hmm... it's not here" page and do not navigate to the report end.

What alternative solutions did you explore? (Optional)

[ahmdshrif]

Proposal

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

Tapping a deeplink to a deleted message should land on the persistent "Hmm... it's not here" page. Instead, tapping it inside the same chat only flashes that page for a moment, and opening the same link from the self DM never shows it at all — the user is silently dropped into the workspace chat.

What is the root cause of that problem?

1. A deleted message is not removed from Onyx — it stays in the reportActions_ collection and is only hidden: shouldReportActionBeVisible returns false for deleted actions (

   App/src/libs/ReportActionsUtils.ts

   Lines 1316 to 1318 in d1835ca

   	// All other actions are displayed except thread parents, deleted, or non-pending actions
   	return !!reportAction.pendingAction || !isDeletedAction(reportAction) || isDeletedParentAction(reportAction) || isReversedTransaction(reportAction);

   ). So when LinkedActionNotFoundGate mounts for the deeplink, isLinkedActionDeleted is true on the very first render (

   App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

   Lines 82 to 86 in d1835ca

   	const actionReportID = linkedAction?.reportID ?? reportIDFromRoute;
   	const hasNoActionReportID = !!linkedAction && !actionReportID;
   	const isActionHidden =
   	!!linkedAction && !!actionReportID && !isReportActionVisible(linkedAction, actionReportID, canUserPerformWriteAction(report, isReportArchived), visibleReportActionsData);
   	const isLinkedActionDeleted = hasNoActionReportID || isActionHidden;

   ).
2. That makes shouldShowNotFoundLinkedAction true (

   App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

   Lines 117 to 118 in d1835ca

   	const shouldShowNotFoundLinkedAction =
   	!wasEverVisible && !isLinkedActionInaccessibleWhisper && (isLinkedActionDeleted || (hasSeenLoadingCycle && !isLoadingInitialReportActions && !linkedAction));

   ), and the gate renders FullPageNotFoundView — this is the "Hmm... it's not here" the tester sees.
3. But the same flag is fed to useAutoNavigateForDeletedLinkedAction (

   App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

   Line 190 in d1835ca

   useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction, navigateToEndOfReport);

   ), whose useLayoutEffect immediately calls navigateToEndOfReport() → Navigation.setParams({reportActionID: undefined}) (

   App/src/pages/inbox/hooks/useAutoNavigateForDeletedLinkedAction.ts

   Lines 10 to 19 in d1835ca

   	function useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction: boolean, navigateToEndOfReport: () => void) {
   	useLayoutEffect(() => {
   	if (!shouldShowNotFoundLinkedAction) {
   	return;
   	}
   	navigateToEndOfReport();
   	// eslint-disable-next-line react-hooks/exhaustive-deps
   	}, [shouldShowNotFoundLinkedAction]);
   	}

   ,

   App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

   Lines 183 to 185 in d1835ca

   	const navigateToEndOfReport = () => {
   	Navigation.setParams({reportActionID: undefined}, route.key, navigatorKey);
   	};

   ). Once the param is cleared, the outer guard renders plain children (

   App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

   Lines 39 to 44 in d1835ca

   	if (!reportActionIDFromRoute) {
   	return children;
   	}
   	return (
   	<LinkedActionNotFoundGate

   ). The not-found page therefore can NEVER persist — whether the user glimpses it is a frame-timing race.
4. The STRUCTURAL cause: shouldShowNotFoundLinkedAction is an OR of two distinct states — (a) action exists in Onyx but is deleted/hidden, and (b) action never existed (!linkedAction after loading). PR #82508 (fixing #79163) added the auto-navigate hook for case (b) only — its test appends a garbage ID /123456789 to a URL and verifies "no Not Found page is shown". Wiring the hook to the whole OR flag made deleted messages (case a) inherit the garbage-ID auto-recovery by accident.

This chain explains every symptom detail:

• Steps 6–7 (tap inside the same chat): the screen is already visible, and on Android the native stack commits the frame synchronously before the layout effect clears the param (the file's own comment notes this at

  App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

  Lines 110 to 113 in d1835ca

  	// When wasEverVisible is true and the action disappears, the cleanup effect below
  	// handles navigation via setParams instead. Gating on !wasEverVisible here prevents
  	// a flash of the "not found" page on mobile (NativeStackView commits UI synchronously
  	// before the effect can fire).

  ) → brief flash.
• Steps 8–10 (open from self DM): a new ReportScreen is pushed; the layout effect fires during the push transition, before the screen is presented → the param is gone before anything paints → user lands straight in the workspace chat with no not-found page.
• Steps 11–12 (flaky repeat taps): the same commit-vs-effect race, timing-dependent per tap — which is also why this reproduces on Android App and not web (web clears the param pre-paint).

There is a single call site — LinkedActionNotFoundGuard is used only in ReportScreen (

App/src/pages/inbox/ReportScreen.tsx

Line 130 in d1835ca

<LinkedActionNotFoundGuard>

), the hook is used only in this gate, and there are no platform-specific variants of either file, so the fix below covers all paths and platforms.

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

One-line change at the hook call site — auto-recover only when the action never existed, and let deleted actions keep the persistent not-found page:

// LinkedActionNotFoundGuard.tsx (L190)
useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction && !isLinkedActionDeleted, navigateToEndOfReport);

With this, a deeplink to a deleted message shows "Hmm... it's not here" persistently — with the back button and the already-rendered "Go to chat instead" link (L196–L201) as the recovery path — while a URL with a never-existing action ID still auto-opens the report exactly as PR #82508 intended. Regression safety in one sentence: the whisper effect and the deleted-while-viewing cleanup effect (wasEverVisible path) are untouched, and the missing-ID branch still auto-navigates, so #79163's QA test still passes.

Why the obvious simple fix does NOT work: deleting useAutoNavigateForDeletedLinkedAction (a straight revert) directly regresses #79163 — a link with a never-existing action ID would dead-end on "Not found", the exact case PR #82508's QA step checks ("Verify that no 'Not Found' page is shown and the report opens"). And any fix that merely hides the flash (deferring the render until effects run) fails the stated Expected Result — the page must show and STAY for deleted messages — and still leaves the self-DM path silently landing in the chat.

I would also extend tests/navigation/LinkedActionNotFoundGuardTest.tsx (it currently mocks isReportActionVisible to true, so the deleted branch is uncovered): deleted linked action on mount → setParams NOT called; missing action after a loading cycle → setParams called once.

What alternative solutions did you explore? (Optional)

1. Remove the auto-navigate hook entirely — simplest diff, but regresses the intentional #82508/#79163 behavior for never-existing IDs (see above).
2. Split the flag explicitly (isLinkedActionMissing = hasSeenLoadingCycle && !isLoadingInitialReportActions && !linkedAction) and pass !wasEverVisible && !isLinkedActionInaccessibleWhisper && isLinkedActionMissing to the hook, renaming it useAutoNavigateForMissingLinkedAction — behaviorally identical to the headline fix; nice-to-have polish the PR can include, but not required for correctness.
3. Debounce/delay the auto-navigation so the page shows "long enough" — still violates the Expected Result (the page must persist) and keeps the timing race alive.

[samranahm]

Proposal

What is the root cause of that problem?

When a user taps a deeplink that points to a report action that was deleted (for example the copied message link from step 4 after the message is removed in step 5), NewDot opens the report screen and briefly renders the report before it can determine that the linked report action no longer exists. The "Hmm... it's not here" not-found state flashes and then disappears because the not-found decision is made from Onyx data that is still loading.

The report screen (ReportScreen.tsx) computes whether to show the not-found page from the linked report action's availability. On a fresh deeplink open, openReport is dispatched with the reportActionID, and while the report/report-actions collection is still being fetched, the "linked action missing" condition is transiently true, then flips once metadata arrives. That transient flip is what produces the brief "Hmm... it's not here" flash rather than a stable not-found screen.

The self-DM difference in steps 8 to 10 happens because when the same link is opened from the self DM, the deeplink resolution navigates to the target reportID (the workspace chat) and lands on the report without treating the missing reportActionID as invalid, so the user is directed into the workspace chat instead of the not-found page. The invalid reportActionID is not consistently gating navigation across the two entry points, so the not-found state is decided differently depending on where the link was tapped.

The gating for the linked report action lives in the report screen's not-found computation and the deeplink handling in the navigation layer, so the behavior is not deterministic while the linked action data is loading.

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

1. In ReportScreen.tsx, make the not-found decision for a linked report action wait until the report actions for that report have finished loading, so it does not flip from "not found" to "found" (or the reverse) mid-load. The screen should treat the state as loading (show the skeleton/loading indicator) while reportActionID is present but the report actions metadata has not settled, and only resolve to the not-found page once loading is complete and the action is confirmed absent. This removes the brief flash because the not-found state is no longer derived from partially loaded data.

2. Ensure the same linked-action validity check is applied regardless of the entry point (workspace chat versus self DM). The deeplink handler should resolve the reportActionID against the loaded report actions and route to the not-found page when the action is absent, instead of silently landing on the report. Reusing the report screen's single "is linked action available" check for both entry points makes the outcome deterministic, so opening the invalid link from the self DM lands on "Hmm... it's not here" like the workspace chat path.

Grounding this in the report screen and its not-found gating keeps the fix centralized in one condition rather than duplicating logic per navigation source.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[Abdulloh0109]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 14:04:09 UTC.

Proposal

What is the root cause of that problem?

The LinkedActionNotFoundGate asks a single flag to do two contradictory jobs in the same render pass: mount the blocking "Hmm... it's not here" page, and immediately navigate away from it.

When the deep link is tapped, the deleted action is still present in Onyx but no longer visible, so the gate computes isLinkedActionDeleted = true:

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 81 to 86 in d1835ca

	// --- Linked action status ---
	const actionReportID = linkedAction?.reportID ?? reportIDFromRoute;
	const hasNoActionReportID = !!linkedAction && !actionReportID;
	const isActionHidden =
	!!linkedAction && !!actionReportID && !isReportActionVisible(linkedAction, actionReportID, canUserPerformWriteAction(report, isReportArchived), visibleReportActionsData);
	const isLinkedActionDeleted = hasNoActionReportID || isActionHidden;

Because the gate is freshly mounted (key={reportActionIDFromRoute} resets it), wasEverVisible is still false, so shouldShowNotFoundLinkedAction is true on the very first render:

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 117 to 118 in d1835ca

	const shouldShowNotFoundLinkedAction =
	!wasEverVisible && !isLinkedActionInaccessibleWhisper && (isLinkedActionDeleted || (hasSeenLoadingCycle && !isLoadingInitialReportActions && !linkedAction));

That one flag is then consumed twice, in the same pass — it drives the auto-recovery hook, and it is handed to FullPageNotFoundView as shouldShow:

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 190 to 203 in d1835ca

	useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction, navigateToEndOfReport);
	return (
	<FullPageNotFoundView
	shouldShow={shouldShowNotFoundLinkedAction}
	subtitleKey="notFound.commentYouLookingForCannotBeFound"
	subtitleStyle={[styles.textSupporting]}
	shouldShowBackButton={shouldUseNarrowLayout}
	onBackButtonPress={goBack}
	shouldShowLink
	linkTranslationKey="notFound.goToChatInstead"
	subtitleKeyBelowLink="notFound.contactConcierge"
	onLinkPress={navigateToEndOfReport}
	shouldDisplaySearchRouter
	>

FullPageNotFoundView replaces children with the blocking view synchronously during that render, so the page is committed to the native view tree:

App/src/components/BlockingViews/FullPageNotFoundView.tsx

Lines 96 to 128 in d1835ca

	if (shouldShow) {
	StatsCounter('FullPageNotFoundView');
	return (
	<ForceFullScreenView shouldForceFullScreen={shouldForceFullScreen}>
	<HeaderWithBackButton
	onBackButtonPress={onBackButtonPress}
	shouldShowBackButton={shouldShowBackButton}
	shouldDisplaySearchRouter={shouldDisplaySearchRouter && (isMediumScreenWidth || isLargeScreenWidth)}
	/>
	<View
	style={[styles.flex1, styles.blockingViewContainer]}
	testID={testID}
	>
	<BlockingView
	icon={illustrations.ToddBehindCloud}
	iconWidth={variables.modalTopIconWidth}
	iconHeight={variables.modalTopIconHeight}
	title={translate(titleKey)}
	subtitle={subtitleKey && translate(subtitleKey)}
	linkTranslationKey={shouldShowLink ? linkTranslationKey : undefined}
	subtitleKeyBelowLink={subtitleKeyBelowLink}
	onLinkPress={onLinkPress}
	subtitleStyle={subtitleStyle}
	addBottomSafeAreaPadding={addBottomSafeAreaPadding}
	addOfflineIndicatorBottomSafeAreaPadding={addOfflineIndicatorBottomSafeAreaPadding}
	testID="FullPageNotFoundView"
	/>
	</View>
	</ForceFullScreenView>
	);
	}
	return children;

Only afterwards does the hook's useLayoutEffect run and try to undo it:

App/src/pages/inbox/hooks/useAutoNavigateForDeletedLinkedAction.ts

Lines 10 to 18 in d1835ca

	function useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction: boolean, navigateToEndOfReport: () => void) {
	useLayoutEffect(() => {
	if (!shouldShowNotFoundLinkedAction) {
	return;
	}
	navigateToEndOfReport();
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [shouldShowNotFoundLinkedAction]);

And the undo is not synchronous. navigateToEndOfReport calls Navigation.setParams, which is a React Navigation dispatch — it schedules a state update in the navigation container rather than re-rendering in place:

App/src/libs/Navigation/Navigation.ts

Lines 652 to 658 in d1835ca

	function setParams(params: Record<string, unknown>, routeKey = '', targetKey?: string) {
	navigationRef.current?.dispatch({
	...CommonActions.setParams(params),
	source: routeKey,
	...(targetKey && {target: targetKey}),
	});
	}

So the ordering per tap is: render with shouldShow = true → the not-found page is mounted into the native hierarchy → layout effect dispatches SET_PARAMS → the already-mounted page can be presented for one or more frames → the next render sees no reportActionID, the guard early-returns children, and the report appears:

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 39 to 41 in d1835ca

	if (!reportActionIDFromRoute) {
	return children;
	}

That is precisely the "hmm not here briefly" in step 7.

The decisive evidence that this is a defect and not the design: the file already defends against this exact flash on the sibling path, and the deep-link path was left out. When an action is deleted while you are looking at it (wasEverVisible === true), the code deliberately excludes it from shouldShowNotFoundLinkedAction and recovers purely through an effect, and the comment names the hazard outright:

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 106 to 118 in d1835ca

	// Show "comment not found" when the linked action was NEVER visible during this mount:
	// 1. The action exists but is deleted/hidden (and was never visible)
	// 2. The action doesn't exist in the collection after loading completes (and was never visible)
	//
	// When wasEverVisible is true and the action disappears, the cleanup effect below
	// handles navigation via setParams instead. Gating on !wasEverVisible here prevents
	// a flash of the "not found" page on mobile (NativeStackView commits UI synchronously
	// before the effect can fire).
	//
	// Note: the inaccessible whisper case is handled separately by the whisper effect.
	const shouldShowNotFoundLinkedAction =
	!wasEverVisible && !isLinkedActionInaccessibleWhisper && (isLinkedActionDeleted || (hasSeenLoadingCycle && !isLoadingInitialReportActions && !linkedAction));

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 147 to 164 in d1835ca

	// Action was deleted or completely removed while we were viewing it — navigate away.
	// This handles both: (1) action exists but is hidden/deleted, and (2) action was
	// removed from Onyx entirely (e.g. REPORT_PREVIEW nulled out when moving IOU to workspace).
	useEffect(() => {
	if (!wasEverVisible) {
	return;
	}
	const isActionGone = isLinkedActionDeleted || (!linkedAction && !isLoadingInitialReportActions);
	if (!isActionGone) {
	return;
	}
	Navigation.setParams({reportActionID: undefined}, route.key, navigatorKey);
	// Also strip the stale reportActionID from any `backTo` params on sibling routes
	// (e.g. the IOU report screen that was navigated to FROM this deep link).
	if (reportIDFromRoute) {
	cleanStaleReportActionBackToParam(reportIDFromRoute, reportActionIDFromRoute);
	}
	}, [isLinkedActionDeleted, wasEverVisible, linkedAction, isLoadingInitialReportActions, route.key, navigatorKey, reportIDFromRoute, reportActionIDFromRoute]);

Both paths end in the identical recovery — strip reportActionID, show the report at its end — but only the wasEverVisible === true path is protected from rendering the page first. The wasEverVisible === false path (this issue's repro: deep-linking to an already deleted action) still renders it and relies on an effect to take it back. Since useAutoNavigateForDeletedLinkedAction fires unconditionally whenever the flag is true, the page is never a reachable destination — a transient mount is the only thing it can ever produce.

Why steps 8–12 look inconsistent. Nothing differs in the data; only when the flag flips relative to the screen being presented. Tapping the link inside the workspace chat (steps 6–7, 11–12) flips it on a screen that is already on-screen, so the committed frame is visible. Arriving from the self DM (steps 8–10) mounts ReportScreen behind the native stack push, and the param is stripped during the transition, so the transient page is swapped out before the screen is ever presented. That frame-level race is exactly why step 12 reports the flash only "after tapping few times" — it is one intermittent bug, not two.

One further consequence worth flagging: the deep-link path recovers via the hook, which only calls navigateToEndOfReport. It never calls cleanStaleReportActionBackToParam, which the wasEverVisible effect does call (L161-163). So stale reportActionID values in sibling routes' backTo params are cleaned up on one path and silently left behind on the other.

On the stated Expected Result. "Tapping invalid deeplink must direct to hmm not here" is the pre-existing behaviour that Expensify deliberately removed. Issue #79163 (raised internally, Design label, design-reviewed) states the problem as: "we show the user generic not here page informing them that the comment is not to be found. This is however very disruptive while in many cases we could show the report as normal", with the solution: "Show the report if the user has access to it and minimize the feedback to the user about the report action not to be found." That was shipped by PR #82508, which introduced useAutoNavigateForDeletedLinkedAction and whose test step 6 reads: "Verify that no 'Not Found' page is shown and that the original report from step 1 opens correctly."

So step 10 (self DM → lands on the workspace chat, no not-found) is the intended behaviour, and the BrowserStack case TR-3370 still encodes the pre-#82508 expectation and is stale. The genuine regression left by #82508 is the one thing #79163 set out to remove but that still leaks through: a full-page "not here" flash.

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

Make the two recovery paths symmetric — never render the blocking page for a linked action we are about to auto-recover from. The flash exists only because the deep-link path mounts the page and then relies on an asynchronous SET_PARAMS dispatch to remove it; the fix is to never mount it, which is what the wasEverVisible path already does.

In LinkedActionNotFoundGate:

1. Drop the !wasEverVisible guard from the recovery effect (L151-153) so the single effect covers both "deleted while viewing" and "deep-linked to an already-deleted action". This also gives the deep-link path the cleanStaleReportActionBackToParam cleanup it currently misses.
2. Remove the useAutoNavigateForDeletedLinkedAction call (L190) — the unified effect now owns the recovery, and the hook is what forces the page to be mounted-then-unmounted.
3. Stop passing the recovery condition to shouldShow — render children while the param strip is in flight, so FullPageNotFoundView is never committed and no frame can paint it.

Keep the existing Log.info (L120-L145) so the case stays observable in logs.

This is the right layer for three reasons. The flash originates in this gate's own render/effect ordering, not in navigation or in the Onyx data — Navigation.setParams already produces the correct destination, it just lands one commit too late. It resolves the whole issue in one change: the flash in steps 6-7 and the intermittency in steps 11-12 are the same race, so removing the mount makes every entry point deterministically identical to the self-DM path in step 10. And it finishes the job #79163 asked for — the full page "not here" stops being reachable for a deep link the user has access to, rather than being reachable for one frame.

Since #79163 also noted "there should be some feedback" about the missing action, if the team wants that feedback restored it should be added deliberately in the subtle, non-blocking form the design discussion called for — not left as an accidental one-frame full-page flash. I'd treat that as a separate follow-up rather than widen this fix.

I'd also suggest updating BrowserStack case TR-3370, whose expected result still describes the behaviour #82508 intentionally replaced, so this does not get re-reported.

What alternative solutions did you explore? (Optional)

Latch the recovery during render, keeping the hook. Add const [isAutoRecovering, setIsAutoRecovering] = useState(false), set it during render when shouldShowNotFoundLinkedAction is true (the same React-supported during-render pattern the file already uses for wasEverVisible and hasSeenLoadingCycle at L90-L104), and gate shouldShow on !isAutoRecovering. React re-renders synchronously before committing, so the page never reaches the native tree. This is a smaller diff and fixes the flash, but it leaves two overlapping recovery mechanisms in the file and does not fix the missing cleanStaleReportActionBackToParam on the deep-link path — so I prefer unifying them.

Restore the persistent not-found page to match the tester's expected result, by dropping useAutoNavigateForDeletedLinkedAction. I rejected this: it would revert the approved, design-reviewed outcome of #79163 / #82508 and re-introduce the "very disruptive" page that issue was filed to remove.

[melvin-bot]

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