LHN - "Fix" label is displayed on chat prevew after creating an expense with "0" amount.

[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.42-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: #85523
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app)
App Component: Left Hand Navigation (LHN)

Action Performed:

Prerequisite: Account has at least one workspace.

1. Open the staging.new.expensify.com website.
2. Open any workspace chat.
3. Create a manual expense with "0" as amount.
4. Note that a "Fix" label appears on chat preview on LHN.
5. Open the just created expense.
6. Note that no error is visible on report.

Expected Result:

When an expense with "0" as amount is created, label on chat preview should displayed the same action as report.

Actual Result:

When a expense with "0" as amount is created, "Fix" is shown on label on LHN, despite no error being visible on report.

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]

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

[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

Recommendation: REVERT

PR #85192 should be reverted. It refactored the action badge logic and introduced a regression where $0 expenses incorrectly show a "Fix" badge in the LHN even though no error is visible on the report.

Labels: No label changes needed. The issue was initially linked to PR #85523, but that PR only made badges recompute more frequently when policy fields change. The actual bug was introduced by PR #85192 which refactored the red brick road / action badge logic.

📋 Detailed Analysis

Evidence

While PR #85523 was initially suspected (and mentioned in the issue), my investigation revealed that PR #85192 is the actual cause:

1. PR feat: deep link to report preview or message that caused GBR/RBR #85192 (merged March 18, 2026): Refactored the action badge logic

   • Changed from shouldShowRedBrickRoad() to getReasonAndReportActionThatHasRedBrickRoad()
   • Modified how "Fix" badges are determined in src/libs/actions/OnyxDerived/configs/reportAttributes.ts

2. PR Fix LHN report badge reactivity to policy field changes #85523 (merged March 20, 2026): Added policy field change detection

   • This PR only made badges refresh when policy fields change
   • Did not modify the badge computation logic itself

Verification

I verified this by examining:

1. The issue reproduction steps: Creating a manual expense with $0 amount immediately shows "Fix" badge
2. PR feat: deep link to report preview or message that caused GBR/RBR #85192 changes: In reportAttributes.ts, line 235 now sets actionBadge = CONST.REPORT.ACTION_BADGE.FIX when reasonAndReportAction is truthy
3. The badge logic flow:
   • generateReportAttributes() calls getReasonAndReportActionThatHasRedBrickRoad()
   • That function checks hasViolations parameter (line 657 of SidebarUtils.ts)
   • Returns a "Fix" reason if violations exist
   • $0 expenses likely have validation violations, triggering the "Fix" badge

Root Cause

PR #85192 refactored the badge logic but introduced a bug where the "Fix" badge is shown for expenses that have violations but no user-visible errors. The old shouldShowRedBrickRoad() function had different logic that prevented this issue. The new getReasonAndReportActionThatHasRedBrickRoad() function at line 657 of SidebarUtils.ts returns a "Fix" reason whenever hasViolations is true, even when there are no actionable errors visible to the user.

Files affected by PR #85192:

• /home/runner/_work/App/App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts
• /home/runner/_work/App/App/src/libs/SidebarUtils.ts
• /home/runner/_work/App/App/src/libs/ReportUtils.ts

[MelvinBot]

Proposal

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

When a user creates a manual expense with "0" as the amount in a workspace chat, the LHN shows a "Fix" badge on the chat preview, but opening the expense report shows no visible error. The LHN and the report view should be consistent.

What is the root cause of that problem?

The root cause is that getReportActionWithMissingSmartscanFields in ReportUtils.ts passes the chat report (not the expense report) to areRequiredFieldsEmpty when checking transactions inside a REPORTPREVIEW action.

Here is the call chain:

1. reportAttributes.ts processes the workspace chat report and calls generateReportAttributes({ report: chatReport, ... })

2. generateReportAttributes → getAllReportErrors(chatReport, chatReportActions) → hasSmartscanError(chatReportActions, chatReport)

3. hasSmartscanError → getReportActionWithSmartscanError(chatReportActions, chatReport) finds a REPORTPREVIEW action

4. For that REPORTPREVIEW: shouldShowRBRForMissingSmartscanFields(chatReport, expenseReportID) → getReportActionWithMissingSmartscanFields(chatReport, expenseReportID) (ReportUtils.ts:5213-5227)

5. This function iterates the expense report's money request actions but passes the chat report to hasMissingSmartscanFields(transaction, chatReport)

6. Inside areRequiredFieldsEmpty (TransactionUtils/index.ts:650-652):

   const isFromExpenseReport = transactionReport?.type === CONST.REPORT.TYPE.EXPENSE;
   return (isFromExpenseReport && isMerchantMissing(transaction)) || isCreatedMissing(transaction) || (!isFromExpenseReport && getAmount(transaction) === 0);
   

   Since the chat report is not an expense report, isFromExpenseReport is false, so the function evaluates (!isFromExpenseReport && getAmount(transaction) === 0) = true for a $0 expense.

7. This triggers hasSmartscanError → adds a smartscan error to reportErrors → getReasonAndReportActionThatHasRedBrickRoad returns HAS_ERRORS → LHN shows Fix badge.

When the user opens the actual expense report, areRequiredFieldsEmpty is called with the correct expense report, so isFromExpenseReport is true and it only checks isMerchantMissing (not amount===0) — hence no error is shown inside the report.

Note: The "Fix" text badge is only rendered in non-production environments (gated by !isProduction at OptionRowLHN.tsx:164). In production, only the red dot (RBR indicator) would appear, which is why this may appear "not reproducible" in production — the underlying RBR still exists, but the text "Fix" doesn't render.

PR #85523 did not introduce this bug — it only added reactivity for policy field changes. This is a pre-existing issue that was caught during regression testing.

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

In getReportActionWithMissingSmartscanFields (ReportUtils.ts:5213-5227), instead of passing the outer report (which is the chat report) to hasMissingSmartscanFieldsTransactionUtils, look up the transaction's actual report using transaction.reportID:

// Before (buggy):
return hasMissingSmartscanFieldsTransactionUtils(transaction, report);

// After (fix):
const transactionReport = getReport(transaction.reportID) ?? report;
return hasMissingSmartscanFieldsTransactionUtils(transaction, transactionReport);

This ensures areRequiredFieldsEmpty receives the correct report type (expense report) and uses the right validation branch (checking merchant instead of amount===0).

What alternative solutions did you explore? (Optional)

An alternative would be to change areRequiredFieldsEmpty to never treat amount===0 as a missing field for manually-created transactions (distinguishing manual entry from smartscan). However, this would be a broader change with more risk. The targeted fix of passing the correct report is simpler and addresses the root cause directly.

---

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]

Note: The "Fix" text badge is only rendered in non-production environments (gated by !isProduction at OptionRowLHN.tsx:164). In production, only the red dot (RBR indicator) would appear, which is why this may appear "not reproducible" in production — the underlying RBR still exists, but the text "Fix" doesn't render.

We can demote this.