Expense - Expense remain highlighted after navigating back to WS chat

[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: v9.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): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 pro /Chrome
App Component: Money Requests

Action Performed:

1. Navigate to staging.new.expensify.com
2. Create WS
3. Create expense
4. Navigate away from the WS and navigate back

Expected Result:

Expense should not get highlighted after navigating back to WS chat

Actual Result:

Expense remain highlighted after navigating back to WS chat

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

[melvin-bot]

Triggered auto assignment to @marcochavezf (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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: None found

Recommendation: REVERT

PR #85192 introduces a deep linking feature that is intentionally disabled in production but enabled in staging. When clicking an LHN row with an action badge in staging, it navigates to r/reportID/reportActionID, which highlights the specific expense. The issue is that this reportActionID parameter persists in the route when navigating away and back, causing the expense to remain incorrectly highlighted.

Since this bug is staging-only and the feature is already gated from production, reverting will cleanly remove the issue while the navigation/route handling can be fixed properly.

Labels: No label changes needed. This is a Frontend bug (App PR caused it), but it is NOT reproducible in production, so DeployBlockerCash should remain to block the App deploy to production.

📋 Detailed Analysis

Evidence

PR #85192 modified the LHN navigation behavior in src/pages/inbox/sidebar/SidebarLinks.tsx:

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

This code intentionally passes actionTargetReportActionID only in non-production environments (staging). When this parameter is included in the route (r/reportID/reportActionID), it causes the specific report action to be highlighted.

Verification

The PR modifies the exact files involved in LHN navigation and deep linking:

• src/pages/inbox/sidebar/SidebarLinks.tsx - Adds the reportActionID parameter to navigation
• src/libs/actions/OnyxDerived/configs/reportAttributes.ts - Stores the actionTargetReportActionID
• src/components/LHNOptionsList/OptionRowLHNData.tsx - Passes the actionTargetReportActionID to LHN rows

The bug reproduction matches exactly: create expense → navigate away → navigate back = expense remains highlighted.

Root Cause

When clicking an LHN row in staging, the navigation includes the reportActionID parameter which highlights that specific action. However, when navigating away from the workspace and then navigating back, the route parameter persists (likely through browser history or route state), causing the highlight to remain when it should be cleared.

The feature works as designed for the initial deep link, but fails to clear the highlighting state when returning to the report through normal navigation.

[aimane-chnaif]

I think this is expected.

[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 away, and navigating back, the expense remains highlighted with the messageHighlightBG background color. This only reproduces on staging (not production).

What is the root cause of that problem?

PR #85192 introduced deep-linking to specific report actions when clicking an LHN row that has a GBR/RBR badge. When clicking a workspace chat in the LHN, SidebarLinks.showReportPage (SidebarLinks.tsx:72) now passes actionTargetReportActionID as a route param, navigating to r/{reportID}/{reportActionID}.

This reportActionID route param drives a static (non-animated) highlight in PureReportActionItem (line 570-586):

isReportActionLinked = linkedReportActionID === action.reportActionID
highlightedBackgroundColorIfNeeded = isReportActionLinked ? messageHighlightBG : {}

The problem is that reportActionID is never cleared from route params after the user views the highlighted action. It is only cleared in 5 specific edge cases in ReportScreen.tsx (invalid ID, one-transaction-thread redirect, navigate-to-end, deleted action, inaccessible whisper) — none of which apply to normal navigation. When the user navigates away and returns, React Navigation preserves the route params, so the highlight persists indefinitely.

This only affects staging because the deep-link is gated: isProduction ? undefined : option.actionTargetReportActionID (SidebarLinks.tsx:72). Once this gate is removed (as stated in the PR description), the bug will affect production.

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

In ReportScreen.tsx, clear the reportActionID from route params after the highlight has been shown. This can be done by adding a timeout (matching the expected highlight visibility duration) that calls navigation.setParams({reportActionID: ''}) after the user has had time to see the highlighted action and it has scrolled into view.

Alternatively, in PureReportActionItem.tsx, switch the deep-link highlight from a static messageHighlightBG background to using the existing useAnimatedHighlightStyle hook (which auto-fades over ~3.5 seconds), so the highlight naturally disappears regardless of route param persistence.

What alternative solutions did you explore? (Optional)

• Clear reportActionID on screen blur: Using useFocusEffect cleanup to clear the param when the user navigates away. This would prevent the highlight on return but wouldn't address the persistent highlight while the user is actively viewing the report.
• Clear on scroll: Clear reportActionID when the user scrolls away from the linked action. More complex and potentially fragile.

---

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.

[hoangzinh]

I think this is expected.

Same thought