Expense - Not here page opens on Inbox after deleting expense from Reports

[jponikarchuk]

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.3.40-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85192
Email or phone of affected tester (no customers): sdjsdjosijnsodiosd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Go to other chat.
5. Go to workspace chat.
6. Go to Reports > Expenses.
7. Delete the expense from Step 3.
8. Go to Inbox.

Expected Result:

Workspace chat will open.

Actual Result:

Not here page opens.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @hoangzinh

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #85192

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #85192 - "feat: deep link to report preview or message that caused GBR/RBR" by @aimane-chnaif (High confidence)
Related Issues: #85665 (same root cause - expense highlighting)

Recommendation: ROLL FORWARD

A fix is needed to handle stale actionTargetReportActionID references. Reverting would remove the entire deep-linking feature from staging testing. The fix should invalidate or clear the actionTargetReportActionID when the target report action is deleted.

Labels: No label changes made (keeping DeployBlockerCash as this is a frontend bug in App)

📋 Detailed Analysis

Evidence

PR #85192 introduces deep linking to specific report actions (GBR/RBR) when clicking LHN rows. This feature is intentionally gated to staging only (not production) as noted in the PR description.

Key code change in src/pages/inbox/sidebar/SidebarLinks.tsx line 76:

Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(option.reportID, isProduction ? undefined : option.actionTargetReportActionID));

The feature only activates when isProduction === false (staging environment), which perfectly matches the reproduction pattern:

• ✅ Reproducible in staging
• ❌ NOT reproducible in production

Verification

The PR modifies these critical files related to the bug:

• src/pages/inbox/sidebar/SidebarLinks.tsx - Passes actionTargetReportActionID to navigation
• src/libs/SidebarUtils.ts - Calculates and stores actionTargetReportActionID in report attributes
• src/types/onyx/DerivedValues.ts - Adds actionTargetReportActionID to derived values
• src/libs/actions/OnyxDerived/configs/reportAttributes.ts - Derives the target action ID for badges

Related issue #85665 (expense highlighting) also stems from the same PR and has identical reproduction conditions.

Root Cause

When an expense is deleted from "Reports > Expenses":

1. The expense and its associated reportAction are deleted
2. The derived value actionTargetReportActionID in the report attributes still references the deleted action
3. When navigating to the workspace chat from Inbox, the code attempts to deep link to the non-existent reportActionID
4. ReportScreen.tsx detects the linked action is invalid and shows "Not here page" via shouldShowNotFoundLinkedAction (line 497-504)

The fix needs to:

• Invalidate/clear actionTargetReportActionID when the target report action is deleted
• Or handle gracefully by falling back to normal navigation when the action is no longer visible
• Update the derived value calculation to check if the action still exists

[MelvinBot]

Proposal

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

After creating an expense in a workspace chat, navigating to Reports > Expenses, deleting the expense, and then going back to Inbox — a "Not here" page appears instead of the workspace chat. This is reproducible on staging but not production.

What is the root cause of that problem?

PR #85192 introduced LHN deep-linking to specific reportActions associated with GBR/RBR badges. In non-production environments, when clicking a workspace chat in the LHN, the route includes an actionTargetReportActionID pointing to the REPORTPREVIEW action (SidebarLinks.tsx:76):

Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(option.reportID, isProduction ? undefined : option.actionTargetReportActionID));

This reportActionID is cached in the navigation state via lastReportRoute. When the user navigates to another tab (Reports > Expenses) and deletes the expense, the REPORTPREVIEW action is marked as deleted (message.deleted is set in IOU/index.ts:8068). When navigating back to Inbox, NavigationTabBar (index.tsx:107-110) re-navigates using the cached route which still contains the stale reportActionID:

const {reportID, reportActionID, referrer, backTo} = lastReportRoute.params;
Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID, reportActionID, referrer, backTo));

ReportScreen then detects the linked action is deleted via isLinkedActionDeleted (ReportScreen.tsx:466-475) and sets isNavigatingToDeletedAction to true (ReportScreen.tsx:906), which triggers shouldShowNotFoundLinkedAction (ReportScreen.tsx:497-504), showing the "Not here" page.

This explains why it's staging-only: the isProduction gate means actionTargetReportActionID is never set in production, so lastReportRoute never caches a reportActionID, and NavigationTabBar re-navigates without one.

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

Option A (recommended): In NavigationTabBar/index.tsx, strip the reportActionID from lastReportRoute.params when re-navigating to the Inbox tab. The reportActionID is a transient deep-link target that should not persist across tab switches — it can become stale if the referenced action is deleted or modified while the user is on another tab. Change line 109 to pass undefined for reportActionID:

Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID, undefined, referrer, backTo));

Option B (defense-in-depth): In ReportScreen.tsx, when isLinkedActionDeleted becomes true during a tab switch (not a fresh navigation), clear the reportActionID param and show the report normally instead of showing the "Not here" page.

Option A addresses the root cause (stale route params) while Option B adds resilience for any other path that might cache a reportActionID.

What alternative solutions did you explore? (Optional)

• Clearing actionTargetReportActionID in reportAttributes on deletion: This would help for the LHN deep-link path but wouldn't fix the NavigationTabBar caching issue. The derived value recomputes asynchronously, so there's also a timing window where the stale value persists.
• Not setting reportActionID for REPORTPREVIEW actions: This would prevent the specific scenario but is too narrow — the deep-linking feature is intended to work with REPORTPREVIEW actions for GBR/RBR.

Note: This is currently gated behind isProduction (staging-only), but per the PR description, this gate will be removed once it passes QA. The fix should be applied before removing the gate.

---

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.

[aimane-chnaif]

What's the expected behavior here? Option A or Option B or anything else?