[$250] Chat-Navigate to link of deleted message leads to the chat rather than not here page

[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: 9.4.15-0
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/folder/13176964/test-cases/41237743
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11 pro /Chrome
App Component: Chat Report View

Action Performed:

1. Navigate to staging.new.expensify.com
2. Go to any chat
3. Send a message
4. Long-press on any message that you have sent and select "Copy Link"
5. Send that link in the chat
6. Delete the message for which you selected "Copy Link"
7. Press on the link in the chat

Expected Result:

Not found page is displayed

Actual Result:

The link navigate to the chat even if the message is deleted

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Recording.5904.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067725645072303426
• Upwork Job ID: 2067725645072303426
• Last Price Increase: 2026-06-25

[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/59f9575e18158823b2bafb78587b76e2d310d9d5edfefb8bc0d853e8e642f8ea

[MelvinBot]

Issue Analysis

Root cause: This is current intended behavior, not a straightforward bug. When you open a deep link to a deleted message, the app does detect the linked action is gone — but it deliberately auto-recovers to the chat instead of dead-ending on the "Hmm... it's not here" page. The redirect is performed by useAutoNavigateForDeletedLinkedAction, whose own comment states it "auto-recovers by clearing the reportActionID param... instead of a dead-end 'not found' screen."

So the test case's Expected Result ("Not found page is displayed") appears to be outdated relative to the current design. The not-found view is still rendered, but LinkedActionNotFoundGuard.tsx:184 immediately strips the reportActionID param, landing the user on the chat.

Recommendation: Confirm the intended product behavior with the team before changing code. If a deep link to a deleted message should still recover to the chat (current design), this test case should be updated. If it should show the not-found page, the fix is to skip the auto-navigate when the action is deleted (vs. merely not-yet-loaded) — see details.

Investigation details & evidence

Code path (src/pages/inbox/LinkedActionNotFoundGuard.tsx):

1. The deleted action is still in Onyx, so it's fetched at L68-70.
2. isLinkedActionDeleted is computed from visibility at L76-80 and feeds shouldShowNotFoundLinkedAction at L111-112.
3. When that flag is true, useAutoNavigateForDeletedLinkedAction fires a useLayoutEffect that calls navigateToEndOfReport() → clears reportActionID → chat is shown.

Secondary contributing factor — a timing window: A just-deleted action that still carries an optimistic pendingAction: DELETE is treated as visible by shouldReportActionBeVisible (ReportActionsUtils.ts:1286) — the !!reportAction.pendingAction clause short-circuits to true. So during the in-flight delete, isLinkedActionDeleted is false and the chat is shown for that reason. After the server clears pendingAction, the action becomes hidden and the auto-navigate path above takes over. Either way the end result is the chat.

Why "intended" is the most likely read: PR #88360 explicitly reverted a dedicated ReportActionNotFoundPage redirect, and PR #87167 added the wasEverVisible gate specifically to prevent a not-found flash. The code is purpose-built to avoid dead-ending on not-found for linked actions.

If the team wants the not-found page to stick for deleted messages: gate the auto-navigate so it only recovers when the action was never present / failed to load, not when it was explicitly deleted — i.e. don't call navigateToEndOfReport() when isLinkedActionDeleted is true. This would diverge from the recently-shipped design, so it needs product sign-off.

Alternative explanations considered: (a) a genuine logic bug in the not-found computation — ruled out, the computation correctly flags the deleted action; the redirect is deliberate. (b) The action not being in Onyx at all — ruled out, deleted actions persist in the REPORT_ACTIONS collection.

Confidence: High on the mechanism (code + in-code comments); the open question is purely product intent (does the test expectation still hold?).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93993) to create a draft PR (gates the auto-navigate so deleted-message links show the not-found page).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal (e.g. the current auto-recover-to-chat behavior is correct and the test case should be updated instead).

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-18 21:46:50 UTC.

Proposal

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

Opening a copied/deep link to a message that has since been deleted drops you at the end of the chat instead of the "Not here / comment you're looking for cannot be found" page.

What is the root cause of that problem?

The guard detects the deleted action correctly — the problem is it then auto-bounces away before the not-found page can show.

1. For a deleted message isReportActionVisible returns false, so isLinkedActionDeleted is true and shouldShowNotFoundLinkedAction becomes true. FullPageNotFoundView is wired to render the "Not here" page in exactly this state.
   

   App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

   Lines 111 to 112 in a1cd9a8

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

2. But the guard also calls useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction, …). The moment that flag is true its useLayoutEffect fires navigateToEndOfReport(), which setParams({reportActionID: undefined}) — stripping the action id. The outer guard then sees no reportActionID and just renders the chat. On web the layout-effect runs pre-paint, so the not-found page never appears.
   

   App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

   Line 184 in a1cd9a8

   useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction, navigateToEndOfReport);

   
   

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

   Lines 10 to 19 in a1cd9a8

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

Structural cause: this hook fires only in the !wasEverVisible deep-link case (the page case), so it makes FullPageNotFoundView unreachable. The page even ships a manual "Go to chat instead" link for users who want the chat — the auto-bounce defeats that affordance.

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 186 to 196 in a1cd9a8

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

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

Remove the auto-navigate call so the not-found page renders:

// delete this line in LinkedActionNotFoundGuard.tsx
useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction, navigateToEndOfReport);

Users still reach the chat via the existing "Go to chat instead" link (L193/L195). Regression safety: the "deleted while I was viewing it" case (e.g. REPORT_PREVIEW nulled when moving an IOU to a workspace) is handled by a separate cleanup effect gated on wasEverVisible (L144-L158), which is mutually exclusive with this path and stays untouched; live links still scroll normally.

What alternative solutions did you explore? (Optional)

• Gating the hook as shouldShowNotFoundLinkedAction && wasEverVisible: this never fires, because shouldShowNotFoundLinkedAction already requires !wasEverVisible (L111) — a dead, always-false condition rather than a real fix. Deleting the call is the honest equivalent.
• Loosening the visibility check so the action stays "visible": wrong layer — it would resurrect a deleted message in the report.

[lorretheboy]

Proposal

What is the root cause of that problem?

When you deep-link to a deleted message, LinkedActionNotFoundGate correctly detects it: the linked action is hidden/deleted (via isReportActionVisible), wasEverVisible stays false, and shouldShowNotFoundLinkedAction becomes true — so FullPageNotFoundView is set to show.

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 111 to 112 in a1cd9a8

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

But that not-found page never stays on screen, because useAutoNavigateForDeletedLinkedAction fires the instant shouldShowNotFoundLinkedAction is true and calls navigateToEndOfReport():

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Line 184 in a1cd9a8

useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction, navigateToEndOfReport);

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

Lines 10 to 19 in a1cd9a8

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

navigateToEndOfReport() strips reportActionID from the route params:

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 177 to 179 in a1cd9a8

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

With no reportActionID, the outer guard short-circuits and just renders the chat:

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 33 to 35 in a1cd9a8

	if (!reportActionIDFromRoute) {
	return children;
	}

So the causal chain is: deep-link to deleted action → shouldShowNotFoundLinkedAction becomes true → the auto-navigate hook clears reportActionID before the not-found page is committed → guard re-renders with no action ID → falls through to the chat. The hook auto-recovers for every never-visible not-found case, which is exactly this deleted-message scenario, so the not-found page is effectively unreachable.

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

Stop auto-navigating away for the deep-link-to-deleted-action case and let FullPageNotFoundView render. The "Go to chat instead" link on that view already calls navigateToEndOfReport, giving the user the manual recovery the hook was doing automatically:

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 185 to 200 in a1cd9a8

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

Concretely, remove the useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction, navigateToEndOfReport) call (and the now-unused hook). The genuine "deleted while I was viewing it" case is already handled separately — that path is gated on wasEverVisible and navigates away via its own effect — so dropping the hook only affects the never-visible deep-link case, which is the one that should show the not-found page.

App/src/pages/inbox/LinkedActionNotFoundGuard.tsx

Lines 144 to 158 in a1cd9a8

	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]);

What alternative solutions did you explore? (Optional)

Keep the hook but guard it so it only auto-navigates for the inaccessible-whisper case (already handled by its own effect) and never for isLinkedActionDeleted — but that just duplicates logic; removing the hook is simpler and aligns the behavior with the expected not-found page.

[MobileMage]

Proposal

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

When you "Copy Link" on a message, paste that link into the chat, then delete the original message and click the pasted link, the app navigates to the bottom of the chat instead of showing the "Not here / comment not found" page. The expected behavior is the FullPageNotFoundView because the linked report action no longer exists as a visible message.

What is the root cause of that problem?

The deep link from "Copy Link" is ${environmentURL}/r/${originalReportID}/${reportActionID}, which resolves to ROUTES.REPORT_WITH_ID with a reportActionID param. ReportScreen wraps its content in LinkedActionNotFoundGuard, and that guard owns the decision of whether to render the NotFound page for a linked action.

The guard's classification is actually correct. When a message is deleted, deleteReportComment writes message: [{html: '', text: '', isDeletedParentAction}] and, once the API confirms, successData merges pendingAction: null while leaving the empty message in place — so the action stays in Onyx as a deleted stub. The guard reads it via getReportActionByIDSelector, runs it through isReportActionVisible, and shouldReportActionBeVisible returns false because the final line evaluates !!pendingAction || !isDeletedAction(...) || isDeletedParentAction(...) || isReversedTransaction(...) — with no pendingAction, an empty html (so isDeletedAction is true), and no surviving thread replies, every clause is false:

App/src/libs/ReportActionsUtils.ts

Lines 1285 to 1286 in a1cd9a8

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

So isActionHidden is true, isLinkedActionDeleted is true, and shouldShowNotFoundLinkedAction becomes true. The guard wants to show NotFound. The problem is the very last hook before the render, useAutoNavigateForDeletedLinkedAction, which fires a useLayoutEffect that calls navigateToEndOfReport() the moment shouldShowNotFoundLinkedAction is true. navigateToEndOfReport strips the reportActionID param, the guard re-renders with no linked action to guard, and you land at the bottom of the chat:

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

Lines 10 to 18 in a1cd9a8

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

This is redundant with — and overrides — the dedicated cleanup effect at LinkedActionNotFoundGuard.tsx (lines 144-158), which already handles the legitimate "action vanished while you were looking at it" case (e.g. a REPORT_PREVIEW nulled out when an IOU is moved to a workspace). That effect is correctly gated on wasEverVisible, so it only auto-recovers an action you had already seen. useAutoNavigateForDeletedLinkedAction has no such gate — it bounces away for every not-found case, including a freshly-deleted message that was never visible during this mount, which is exactly the "comment not found" case the page exists for. The bug escaped the existing LinkedActionNotFoundGuardTest only because that test mocks isReportActionVisible: () => true, so the deleted-but-present action is never classified as not-found there.

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

Remove the unconditional auto-navigation so the NotFound page is actually rendered for a deleted linked action. The useAutoNavigateForDeletedLinkedAction(shouldShowNotFoundLinkedAction, navigateToEndOfReport) call at LinkedActionNotFoundGuard.tsx line 184 should be deleted (along with the now-unused hook file and its import on line 22). The genuine auto-recovery path — an action that wasEverVisible and then disappeared — is already covered by the cleanup effect at lines 144-158, so nothing is lost by dropping the blanket redirect. After this change, when shouldShowNotFoundLinkedAction is true, the guard simply renders:

<FullPageNotFoundView shouldShow={shouldShowNotFoundLinkedAction} subtitleKey="notFound.commentYouLookingForCannotBeFound" ... />

This is safe for the edge cases. Still-valid links are unaffected because isReportActionVisible returns true, so shouldShowNotFoundLinkedAction is false. Thread parents whose message was deleted but still have replies stay navigable: shouldReportActionBeVisible returns true via the isDeletedParentAction(reportAction) clause (which requires childVisibleActionCount > 0), so they are not treated as deleted. The inaccessible-whisper branch keeps its own setParams effect (lines 161-175) and is explicitly excluded from shouldShowNotFoundLinkedAction, so whisper handling is untouched. Offline deletes set pendingAction: DELETE, which keeps shouldReportActionBeVisible true (first clause), so the strike-through message still renders offline rather than flashing NotFound — only the confirmed delete trips the page, matching the report.

What alternative solutions did you explore? (Optional)

I considered gating the hook on isLinkedActionDeleted being false (only auto-navigate for the "fully removed from Onyx" case, not the "deleted stub" case), but that just re-implements the wasEverVisible logic the cleanup effect already encapsulates and would leave two competing effects writing the same param — deleting the redundant hook is cleaner and keeps a single source of truth for auto-recovery.

[melvin-bot]

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

[melvin-bot]

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

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.