Expense - IOU receiver has green dot in LHN turns pay badge on revisit

[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.74-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-28774/folder/13176706
Email or phone of affected tester (no customers): applausetester+s7@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Money Requests

Action Performed:

Pre-condition
Payment currency set as USD for user A & B

1. Login new expensifail account - A

2. Login gmail account - user B

3. Launch app

4. As user B , send an IOU in USD

5. Open user A account

6. Note green dot is shown in LHN chat

7. Open the chat & navigate back to LHN

8. Note pay badge is shown in LHN

Expected Result:

Iou receiver must show pay badge on lhn

Actual Result:

IOU receiver has green dot in LHN turns pay badge on revisit.

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: @Pujan92

Issue Owner

Current Issue Owner: @aimane-chnaif

[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.

[melvin-bot]

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

[melvin-bot]

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

[MelvinBot]

Proposal

What is the root cause of that problem?

When a Pusher event delivers an IOU to the receiver, the chat report's hasOutstandingChildRequest flag is set to true immediately, which triggers the green GBR dot in the LHN. However, the action badge (PAY) requires getIOUReportActionWithBadge to look up the REPORT_PREVIEW action and its child IOU report. This function reads from module-level deprecated Onyx connections (allReportActions and deprecatedAllReports) which may not yet be updated when the reportAttributes derived value recomputes. So the derived value fires with hasOutstandingChildRequest=true (green dot) but actionBadge=undefined (no PAY text).

When the user opens the chat and navigates back, OpenReport fetches full data, the global connections catch up, and reportAttributes recomputes correctly with actionBadge='pay'.

Note: The badge text is only rendered in non-production builds (!isProduction guard in InfoBadge), which is why this is reproducible in staging but not production.

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

Thread the reports and reportActions data that the reportAttributes derived value already receives as parameters down through the call chain, so getIOUReportActionWithBadge and getReportOrDraftReport use the up-to-date data from the derived value computation instead of reading from stale module-level Onyx connections.

Specifically:

1. Add optional reports and reportActions parameters to getIOUReportActionWithBadge in ReportWorkflow.ts:300, and use the passed-in reportActions instead of calling getAllReportActionsFromIOU(), and the passed-in reports for looking up the child IOU report instead of calling getReportOrDraftReport.
2. Similarly update getBadgeFromIOUReport at ReportWorkflow.ts:265 to accept and forward these parameters to canIOUBePaid.
3. Pass the derived value's reports/reportActions from generateReportAttributes through getReasonAndReportActionThatRequiresAttention into getIOUReportActionWithBadge.

This ensures the badge computation uses the same consistent snapshot of data that triggered the recomputation, eliminating the race condition.

What alternative solutions did you explore?

An alternative would be to debounce or defer the reportAttributes computation to wait for all global connections to settle after a Pusher batch. However, this would add latency to all LHN updates and is a less targeted fix. Threading the data through function parameters is more surgical and also reduces reliance on deprecated global Onyx connections (a broader codebase goal).

---

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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #87991 - "Refactor: isolate allReports from shouldReportActionBeVisible function" by @shubham1206agra (Low confidence) — see detailed analysis below
Related Issues: #84764 (GBR/RBR Action Badge feature)

Recommendation: NEEDS INVESTIGATION

The bug is a frontend timing issue in the LHN action badge computation for IOU receiver chat rows. A definitive causing PR could not be identified with confidence from the staging list. The PR author and reviewers of the most likely candidate PR should confirm whether their changes could introduce the described timing regression.

Assigned: @shubham1206agra (PR author of #87991), @mountiny (assigned responder per bot)
Labels: DeployBlockerCash kept — the fix, if needed, is in Expensify/App. DeployBlocker label is not present and should not be added.

📋 Detailed Analysis

Evidence

Bug description: When User A receives an IOU from User B, the LHN chat row initially shows a green dot (GBR without action badge). After User A opens the chat and navigates back to LHN, the green dot is replaced by the correct "Pay" badge. Staging only. Android Native.

Staging PRs reviewed: All 23 PRs in the StagingDeployCash checklist (#90562) were examined.

LHN badge data path:

1. LHNOptionsList reads reportAttributes from ONYXKEYS.DERIVED.REPORT_ATTRIBUTES (via useReportAttributes hook).
2. The reportAttributes OnyxDerived value calls generateReportAttributes → getReasonAndReportActionThatRequiresAttention → getIOUReportActionWithBadge.
3. getIOUReportActionWithBadge (in src/libs/actions/IOU/ReportWorkflow.ts) reads directly from getAllReportActionsFromIOU() — a module-level global variable in src/libs/actions/IOU/index.ts — to find the REPORT_PREVIEW action for the chat report.
4. When that action is found and canIOUBePaid returns true, actionBadge = PAY is set.
5. If the REPORT_PREVIEW action is not found in global state at computation time, actionBadge is undefined, producing a green dot with no badge text.

Timing race: The reportAttributes OnyxDerived computation is triggered by REPORT_ACTIONS dependency updates. However, getIOUReportActionWithBadge reads from a separate Onyx.connect subscriber (allReportActions in IOU/index.ts). If the OnyxDerived computation executes before that subscriber receives the REPORT_PREVIEW action, the badge is computed as undefined. Opening the chat triggers an OpenReport API call that refreshes data, which then triggers correct recomputation.

Why staging-only: This timing window may have been widened or newly exposed by changes in this staging cycle. The most relevant staging PR is #87991, which removed allReports as a dependency from the visibleReportActions derived value and removed the "reports changed — recompute actions that depend on report existence" block. While that change is to visibleReportActions (not reportAttributes), it may have altered the order in which Onyx subscribers and derived values settle after initial data load.

Verification

Affected code:

• src/libs/actions/IOU/ReportWorkflow.ts — getIOUReportActionWithBadge function reads getAllReportActionsFromIOU() global state.
• src/libs/ReportUtils.ts — getReasonAndReportActionThatRequiresAttention uses global getAllReportActions and calls into ReportWorkflow.
• src/libs/actions/OnyxDerived/configs/reportAttributes.ts — computes brickRoadStatus and actionBadge for each report.
• src/components/LHNOptionsList/OptionRowLHN/OptionRow/InfoBadge.tsx — renders green dot when brickRoadIndicator === INFO and actionBadge is undefined.

PRs that modify LHN directly: #90334 (refactor OfflineWrapper/ProductTrainingTooltip) and #90332 (rename OptionRowAvatar) — both are pure refactors with no functional change to badge logic.

Candidate PR: #87991 modifies src/libs/ReportActionsUtils.ts (removes allReports parameter from shouldReportActionBeVisible) and src/libs/actions/OnyxDerived/configs/visibleReportActions.ts (removes REPORT dependency and re-evaluation block). Neither change touches reportAttributes directly, but indirect ordering effects cannot be ruled out without runtime profiling.

Root Cause

The getIOUReportActionWithBadge function reads from a module-level global (allReportActions in IOU/index.ts) rather than from the reportActions collection passed as a parameter to generateReportAttributes. On initial load, when the OnyxDerived reportAttributes computation is triggered for the chat report, the IOU module's global state may not yet include the chat report's REPORT_PREVIEW action. This causes actionBadge to be undefined, displaying only the green dot. The badge updates correctly after opening the chat (triggering an API refresh), which repopulates the global state and triggers a correct recomputation.

A proper fix would ensure that getIOUReportActionWithBadge uses the reportActions collection already available as a parameter in generateReportAttributes, rather than reading from potentially-stale global state.