Expense - LHN displays B report name but showing A reports status as "Pay" instead "submit".

[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.37-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85025
Email or phone of affected tester (no customers): dreamnitethedragon+hshdhdhd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Android web
App Component: Left Hand Navigation (LHN)

Action Performed:

1. Launch app
2. Create a workspace
3. Open workspace chat
4. Create 2 reports A & B
5. In A report, create a manual expense entering merchant and category
6. Submit and approve the expense
7. In B report, create a manual expense entering merchant and category
8. Note in LHN

Expected Result:

LHN displays B report name so it should display B status as "submit".

Actual Result:

LHN displays B report name but showing A reports status as "Pay" instead "submit".

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: @aimane-chnaif

[melvin-bot]

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

[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: #85025 - "feat: Expand GBR/RBR with an action badge" by @aimane-chnaif (High confidence)
Related Issues: #85187 (same root cause - PR #85025)

Recommendation: REVERT

PR #85025 introduces action badges (Submit, Approve, Pay, Fix) to replace the green/red dots in the LHN. However, the implementation has a critical flaw: when multiple expense reports exist under the same workspace chat, the action badge system stores only ONE badge per chat report, causing incorrect badge display across different expense reports.

Labels: This is a frontend bug caused by App PR #85025. The current labels are correct - keeping DeployBlockerCash since an App PR caused the issue and it blocks the App deploy.

Detailed Analysis

Evidence

• Issue reproducible on staging v9.3.37-0 where PR feat: Expand GBR/RBR with an "action badge" #85025 is deployed
• Marked as "N/A - new feature, doesn not exist in prod" - confirms new feature from PR feat: Expand GBR/RBR with an "action badge" #85025
• Feature is intentionally gated to staging only (see !isProduction check in OptionRowLHN.tsx:88)
• melvin-bot automatically assigned to author of PR feat: Expand GBR/RBR with an "action badge" #85025
• PR feat: Expand GBR/RBR with an "action badge" #85025 merged on 2026-03-12 and is in the StagingDeployCash checklist

Verification

Affected files modified by PR #85025:

• src/libs/actions/IOU/index.ts - Contains getIOUReportActionWithBadge function
• src/libs/actions/OnyxDerived/configs/reportAttributes.ts - Computes and stores action badges
• src/components/LHNOptionsList/OptionRowLHN.tsx - Renders action badges in LHN
• src/libs/SidebarUtils.ts - Line 794: result.actionBadge = reportAttributes?.actionBadge

Confirmed PR #85025 modifies all these files.

Root Cause

The action badge architecture has a fundamental design flaw when multiple expense reports share the same workspace chat:

1. Action badge storage is at chat report level (not per expense report):

   • src/libs/actions/OnyxDerived/configs/reportAttributes.ts lines 220-231 compute action badges and store them in reportAttributes[report.reportID].actionBadge
   • For workspace chats with multiple expense reports (A and B), only ONE badge can be stored per chat

2. Badge propagation overwrites existing badges:

   • Lines 259-282 in reportAttributes.ts propagate error status from IOU reports to parent chats
   • Line 281: reportAttributes[chatReportID].actionBadge = CONST.REPORT.ACTION_BADGE.FIX
   • This overwrites any existing badge without checking if another expense report already set a different badge

3. Badge selection uses first-match logic:

   • getIOUReportActionWithBadge in src/libs/actions/IOU/index.ts:9787-9831 iterates through chat report actions
   • Returns the FIRST action that matches pay/approve/submit conditions
   • Does not distinguish which specific expense report (A or B) the badge should apply to

Scenario from the issue:

• Report A: Status "Pay" (approved, awaiting payment)
• Report B: Status "Submit" (draft, needs submission)
• Both are under the same workspace chat
• The chat report stores ONE actionBadge, which gets set based on Report A
• When Report B displays in LHN, it shows the chat report action badge, which is "Pay" from Report A
• Result: Report B name with Report A status

Why This Happens

The LHN traditionally showed workspace chats (one entry per workspace), not individual expense reports. The action badge was designed for this model - one badge per chat. But users can create multiple expense reports under one workspace, and now each expense report can show in the LHN with different statuses. The badge system was not architected to handle this many-to-one relationship.

[MelvinBot]

Proposal

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

When a workspace chat has two child expense reports (A and B), the LHN row shows Report B's name (the most recent report) but Report A's action badge ("Pay") instead of Report B's ("Submit"). The displayed name and badge are inconsistent because they are derived from different child reports.

What is the root cause of that problem?

The root cause is in getIOUReportActionWithBadge at src/libs/actions/IOU/index.ts:9796. This function determines the action badge for a chat report by iterating through all REPORT_PREVIEW actions using Object.values(chatReportActions).find(...). The .find() method returns the first matching action in iteration order, regardless of which child report is most recent or most relevant.

When the workspace chat has two REPORT_PREVIEW actions (one for Report A, one for Report B), .find() encounters Report A's REPORT_PREVIEW first (created earlier, so earlier key in the object). Report A's canIOUBePaid() returns true, so the function immediately returns the badge PAY and never evaluates Report B's REPORT_PREVIEW (which would yield SUBMIT).

Meanwhile, the LHN row's display name is computed separately by computeReportName (in reportAttributes.ts:234), which shows the most recent child report's name (Report B). This creates the mismatch: B's name + A's badge.

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

In getIOUReportActionWithBadge (src/libs/actions/IOU/index.ts:9796), instead of using .find() which stops at the first match, iterate through all REPORT_PREVIEW actions and select the one whose linked IOU report was most recently created (or has the most recent lastVisibleActionCreated timestamp). This ensures the badge corresponds to the same child report that the LHN display name references.

Concretely: replace the .find() with a loop that collects all actionable REPORT_PREVIEW actions with their badges, then picks the one linked to the most recently created IOU report. This way, when Report B (the most recent) has a SUBMIT badge, that badge is returned instead of Report A's PAY badge.

What alternative solutions did you explore? (Optional)

1. Show the highest-priority badge across all children (PAY > APPROVE > SUBMIT): This would still show "Pay" when any child is payable, even if the most recent report needs "Submit." While arguably correct from an action-priority standpoint, it creates the exact inconsistency reported — B's name with A's badge.

2. Pass the specific IOU report to filter on: getReasonAndReportActionThatRequiresAttention currently passes updatedIouReport as undefined (line 4327 in ReportUtils.ts). If it instead identified which child report's name is displayed and passed that report, getIOUReportActionWithBadge could filter to only that report's REPORT_PREVIEW. This is more surgical but requires threading the "displayed report" context through the call chain.

---

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]

Let's demote this. The feature is only available in staging.