Track expense - "tracked 0.00" is shown in LHN after creating scan expense in OD

[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.7.1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #80120
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: MacBook Air 15.7.3 Chrome
App Component: Left Hand Navigation (LHN)

Action Performed:

1. Sign in to ND with a new gmail account, selecting "Track and budget", do not create a workspace
2. Switch to Classic in Troubleshoot
3. In OD open Expenses - New expense - Scan receipt, upload a valid receipt
4. Refresh the page and make sure "Scanning..." is no longer displayed
5. Click "Try new Expensify", observe system message in the self DM LHN

Expected Result:

System message reads "Tracking $xx for [Merchant]"

Actual Result:

System message in LHN reads "tracked 0.00"

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @mallenexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[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: #80120 - "fix: pass transaction data for unreported expenses" by @cosmicvulpes (High confidence)
Related Issues: #78770 (the issue that PR #80120 was fixing)

Recommendation: REVERT

PR #80120 introduced a regression where track expense messages show "tracked 0.00" in the LHN instead of the proper "Tracking $xx for [Merchant]" format. While the PR fixed one issue (unreported expenses showing "it's not here"), it broke the track expense detection logic for expenses created in OldDot and viewed in NewDot.

Labels: Keeping DeployBlockerCash (this blocks the App deploy)

📋 Detailed Analysis

Evidence

PR #80120 changed the code in src/libs/SearchUIUtils.ts at line 1632:

const reportActionToPass = iouReportAction ?? item.reportAction ?? ({reportActionID} as OnyxTypes.ReportAction);

The problem occurs when both iouReportAction and item.reportAction are undefined, causing the code to fall back to passing a minimal object {reportActionID} that lacks the originalMessage.type field.

Verification

I examined the affected files and traced the data flow:

1. SearchUIUtils.ts (line 1632): The fallback {reportActionID} object is passed to createTransactionThreadReport

2. Report.ts (line 1373): The createTransactionThreadReport function uses this check:

   const isTrackExpense = !iouReport && ReportActionsUtils.isTrackExpenseAction(iouReportAction);

3. ReportActionsUtils.ts (line 1510): The isTrackExpenseAction function requires:

   return isActionOfType(reportAction, CONST.REPORT.ACTIONS.TYPE.IOU) && getOriginalMessage(reportAction)?.type === CONST.IOU.REPORT_ACTION_TYPE.TRACK;

4. ReportUtils.ts (line 5140): The LHN message generation checks isTrackExpenseAction(iouReportAction) to determine whether to show the track expense message format

When originalMessage.type is missing from the reportAction object, the track expense detection fails, causing the LHN to display incorrect message formatting.

Root Cause

The PR attempted to preserve originalMessage.type by passing the full reportAction object (as noted in the comment at line 1631), but the fallback to {reportActionID} as a minimal object defeats this purpose. In the reproduction scenario:

• User creates scan expense in OldDot
• The expense has a valid reportActionID but both iouReportAction and item.reportAction may be undefined when transitioning to NewDot
• The code falls back to {reportActionID} without the necessary originalMessage.type field
• Track expense detection fails
• LHN shows "tracked 0.00" instead of proper formatting

Impact

This affects the HybridApp flow where users create expenses in OldDot and view them in NewDot, which is a critical use case for the transition period.

[OSBotify]

Label Status: No changes needed. The DeployBlockerCash label is correctly applied as this is a frontend bug that requires reverting or fixing PR #80120 in the App repository.

[linhvovan29546]

Hmm, I don’t think our PR caused that regression. The PR only touches the Reports page.