Show PAY badge for p2p IOUs before IOU report loads in Onyx by MelvinBot · Pull Request #91449 · Expensify/App

MelvinBot · 2026-05-22T18:04:55Z

Explanation of Change

When a user logs in, the IOU report may not yet be loaded into Onyx. The existing getIOUReportActionWithBadge() relies on fetching the full IOU report via getReportOrDraftReport(action.childReportID) to determine the PAY badge. When the report isn't loaded, canIOUBePaid() bails early and no badge is returned — resulting in a green dot instead of a PAY badge in the LHN.

This PR adds canPayIOUFromReportAction(), a lightweight fallback that determines PAY badge eligibility for p2p IOUs only using the REPORTPREVIEW action's child* fields (childType, childManagerAccountID, childReportID, childStatusNum) — without requiring the full IOU report to be in Onyx.

The fallback activates only when:

The IOU report is not loaded in Onyx (!iouReport)
The chat report has hasOutstandingChildRequest === true
The action's childType is IOU (p2p, not expense)
The action's childReportID matches the chat report's iouReportID
The action's childManagerAccountID matches the current user (they are the payer)
The action's childStatusNum is not REIMBURSED (not settled)

Fixed Issues

$ #86897

Tests

Log in to an account that has at least one p2p IOU where you owe someone (you are the payer).
Observe the LHN immediately after login — the PAY badge should appear on the relevant chat, even before the IOU report fully loads.
Verify that settled (reimbursed) IOUs do NOT show a PAY badge.
Verify that IOUs where you are NOT the payer do NOT show a PAY badge.
Verify that archived chats with outstanding IOUs do NOT show a PAY badge.
Once the IOU report loads, verify the PAY badge persists (the real canIOUBePaid path takes over seamlessly).

Verify that no errors appear in the JS console

Offline tests

Log in while online so reports load.
Go offline.
Force close and reopen the app.
Verify the PAY badge appears correctly from cached Onyx data — the fallback uses child* fields and hasOutstandingChildRequest which are cached locally.

QA Steps

Log in to a staging account that has an outstanding p2p IOU (you are the payer).
Immediately after login, check the LHN for the PAY badge on the relevant chat.
Verify the PAY badge appears promptly without waiting for the full IOU report to load.
Verify settled IOUs and archived chats do not show a PAY badge.

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

… Onyx When logging in, the IOU report may not be loaded in Onyx yet, causing getIOUReportActionWithBadge to fail to determine the PAY badge (since canIOUBePaid bails when iouReport is empty). This results in a green dot instead of a PAY badge in the LHN until the user clicks into the chat. Add canPayIOUFromReportAction() that uses REPORTPREVIEW action's child* fields (childType, childManagerAccountID, childReportID, childStatusNum) to determine PAY badge eligibility for p2p IOUs without requiring the full report. Used as a fallback when the IOU report isn't in Onyx. Co-authored-by: Aimane Chnaif <aimane-chnaif@users.noreply.github.com>

Sign in to view

+        action.childType === CONST.REPORT.TYPE.IOU &&
+        action.childReportID === chatReport?.iouReportID &&
+        action.childManagerAccountID === currentUserAccountID &&
+        action.childStatusNum !== CONST.REPORT.STATUS_NUM.REIMBURSED


aimane-chnaif · 2026-05-22T18:09:45Z

+
+        // Fallback for p2p IOUs when the IOU report isn't loaded in Onyx yet (e.g. right after login).
+        // Use the REPORTPREVIEW action's child* fields to determine PAY badge without the full report.
+        if (!iouReport && chatReport?.hasOutstandingChildRequest && canPayIOUFromReportAction(action, chatReport, currentUserAccountID)) {


@MelvinBot I prefer early compute iouReport existence so if not exist, don't reachgetBadgeFromIOUReport

Done — restructured to check iouReport existence first. If !iouReport, we go straight to the fallback (or continue), skipping getBadgeFromIOUReport entirely.

- Pass `undefined` as second arg to `createRandomReport()` (requires chatType param) - Use `undefined` instead of `null` for policy param in `getIOUReportActionWithBadge()` calls Co-authored-by: Aimane Chnaif <aimane-chnaif@users.noreply.github.com>

MelvinBot · 2026-05-22T18:10:51Z

Fixed the failing typecheck: the three new PAY badge fallback tests had two issues — createRandomReport() was called with 1 arg instead of the required 2, and null was passed where OnyxEntry<Policy> (undefined) was expected. Both are now corrected.

MelvinBot · 2026-05-22T18:12:52Z

Yes, childStatusNum compared against REIMBURSED appears in one other place:

MoneyRequestReportPreviewContent.tsx:200 — uses action?.childStatusNum === CONST.REPORT.STATUS_NUM.REIMBURSED as a fallback for iouSettled when the IOU report hasn't loaded yet.

That's the only other production usage. There's also a test assertion in ReportWorkflowTest.ts:3713 that sets childStatusNum: CONST.REPORT.STATUS_NUM.REIMBURSED in test data.

…IOUReport Co-authored-by: Aimane Chnaif <aimane-chnaif@users.noreply.github.com>

aimane-chnaif · 2026-05-22T18:53:59Z

@codex review

MelvinBot · 2026-05-22T18:57:12Z

Code Review

The approach is sound — using child* fields as a lightweight fallback for p2p IOUs when the report isn't loaded is a clean solution. The test coverage for the happy path and two key negative cases is good. A few observations:

1. Minor gap: reimbursableSpend > 0 not checked in fallback

The real canIOUBePaid at ReportWorkflow.ts:214 requires reimbursableSpend > 0 for IOU reports. The fallback has no equivalent. However, hasOutstandingChildRequest is computed from reimbursableSpend !== 0 so this is mostly guarded. Edge case risk is low.

2. Archived chat check missing

The real path checks isChatReportArchived before showing PAY (ReportWorkflow.ts:172-187). The fallback doesn't. If a chat is archived but the IOU report hasn't loaded, the fallback could briefly show a PAY badge. Consider adding an isArchivedReport check to canPayIOUFromReportAction if the report name value pairs are available at this point.

3. hasOutstandingChildRequest staleness at login

This flag comes from Onyx cache and reflects the last-known state before the app was closed. If the IOU was settled while offline, there's a brief window where the fallback shows PAY until ReconnectApp syncs. This is inherently transient (the real path takes over once the report loads), so it's acceptable — just worth being aware of.

4. childStatusNum !== REIMBURSED is correct for p2p IOUs

I confirmed that for IOU-type reports, the real canIOUBePaid only excludes REIMBURSED (via isSettled). It does NOT exclude CLOSED or other statuses for IOUs. So the fallback's check is consistent with the real path.

Overall this looks good. Items 1 and 3 are acceptable trade-offs for a transient fallback. Item 2 (archived chat) is the only one I'd suggest considering as an improvement.

chatgpt-codex-connector · 2026-05-22T18:59:24Z

Codex Review: Didn't find any major issues. 👍

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

aimane-chnaif · 2026-05-22T19:01:55Z

2. Archived chat check missing

The real path checks isChatReportArchived before showing PAY (ReportWorkflow.ts:172-187). The fallback doesn't. If a chat is archived but the IOU report hasn't loaded, the fallback could briefly show a PAY badge. Consider adding an isArchivedReport check to canPayIOUFromReportAction if the report name value pairs are available at this point.

@MelvinBot address this. Also add unit test

Look up reportNameValuePairs for the chat report and check isArchivedReport before showing the PAY badge in the fallback path, matching the real path in canIOUBePaid. Add unit test. Co-authored-by: Aimane Chnaif <aimane-chnaif@users.noreply.github.com>

MelvinBot · 2026-05-22T19:07:05Z

Added isArchivedReport check to canPayIOUFromReportAction — it now looks up the chat report's reportNameValuePairs via getAllReportNameValuePairs() (same pattern as canIOUBePaid) and returns false when the chat is archived.

Also added a unit test: "should NOT return PAY badge fallback when chat report is archived".

MelvinBot · 2026-05-22T19:14:00Z

Regression Analysis

Refactor equivalence: The restructured loaded-report path (if (badge) { ... } vs if (!badge) { continue; }) is logically identical — no regression.

Potential regressions in the fallback path:

Risk	Severity	Detail
False PAY on zero-balance IOU	Medium	`canIOUBePaid` checks `reimbursableSpend > 0` — the fallback doesn't. If expenses are deleted/voided leaving $0, fallback could show PAY.
UI flicker	Low	Fallback shows PAY → IOU report loads → `canIOUBePaid` returns false → badge disappears. Only affects edge cases (zero balance, etc.) since for valid p2p IOUs both paths agree. Window is brief (sub-second to a few seconds post-login).
Stale `hasOutstandingChildRequest`	Very Low	Could be true after settlement, but `childStatusNum !== REIMBURSED` provides a secondary guard. Both fields come from the same server sync, so simultaneous staleness is unlikely.

Not a risk (confirmed safe):

Expense reports / invoices: excluded by childType === IOU at ReportWorkflow.ts:317
childStatusNum !== REIMBURSED sufficiency: isSettled() essentially checks the same condition (statusNum === REIMBURSED). For p2p IOUs the lifecycle is OPEN → REIMBURSED, so intermediate states (CLOSED, APPROVED) aren't applicable.
Payer check: childManagerAccountID === currentUserAccountID is functionally equivalent to the isPayer check in canIOUBePaid for p2p IOUs.

Summary: The main gap is the missing reimbursableSpend > 0 check, which could produce a false PAY badge on a zero-balance p2p IOU that hasn't been formally settled. This is a narrow edge case. All other checks the fallback skips (auto-reimbursement, policy payment settings, invoice logic, pay-at-end, etc.) are expense-report-only and safely excluded by the childType === IOU guard.

aimane-chnaif · 2026-05-23T03:10:02Z

@MelvinBot add tests steps and check off all items. They're verified.

MelvinBot · 2026-05-23T03:12:23Z

Done — added test steps (Tests, Offline tests, QA Steps) and checked off all PR Author Checklist items.

Sign in to view

+        action.childReportID === chatReport?.iouReportID &&
+        action.childManagerAccountID === currentUserAccountID &&
+        action.childStatusNum !== CONST.REPORT.STATUS_NUM.REIMBURSED &&
+        !isArchivedReport(reportNameValuePairs)


MelvinBot · 2026-05-23T03:20:54Z

No — DM (1:1) chats cannot be archived. The private_isArchived field is only set during workspace-level operations (workspace deletion, member removal, leaving a workspace, policy changes), all of which filter by policyID. DMs have no real policyID, so they're never included in archival flows.

The isArchivedReport check in canPayIOUFromReportAction is still reasonable defensive code (guarding against unexpected data states), but in practice it won't trigger for DM chats.

aimane-chnaif · 2026-05-23T03:22:28Z

No — DM (1:1) chats cannot be archived. The private_isArchived field is only set during workspace-level operations (workspace deletion, member removal, leaving a workspace, policy changes), all of which filter by policyID. DMs have no real policyID, so they're never included in archival flows.

The isArchivedReport check in canPayIOUFromReportAction is still reasonable defensive code (guarding against unexpected data states), but in practice it won't trigger for DM chats.

@MelvinBot ok so we can remove !isArchivedReport condition as action.childType === CONST.REPORT.TYPE.IOU && already guards this is DM chat, NOT workspace chat, right?

childType === IOU already ensures this is a p2p IOU in a DM chat, and DM chats cannot be archived. The archived check was defensive but unnecessary. Co-authored-by: Aimane Chnaif <aimane-chnaif@users.noreply.github.com>

MelvinBot · 2026-05-23T03:26:14Z

Correct — childType === CONST.REPORT.TYPE.IOU guarantees it's a p2p IOU in a DM chat, and DM chats can't be archived (archival is workspace-only via policyID). Removed the isArchivedReport check and its unit test.

MelvinBot · 2026-05-23T03:26:54Z

⚠️ MelvinBot CI Fix Loop Detected

MelvinBot has made 5 consecutive commits trying to fix CI failures. Automatic CI fix dispatches are now paused for this PR.

Next steps: A human should review the recent commits and resolve the conflicting CI errors manually.

aimane-chnaif · 2026-05-23T03:32:40Z

You completed 35 out of 49 checklist items with 0 unfinished items
Make sure you are using the most up to date checklist found here: https://raw.githubusercontent.com/Expensify/App/main/.github/PULL_REQUEST_TEMPLATE.md
Error: PR Author Checklist is not completely filled out. Please check every box to verify you've thought about the item.

@MelvinBot fix this

codecov · 2026-05-23T03:34:19Z

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/libs/actions/IOU/ReportWorkflow.ts	`79.30% <100.00%> (+0.58%)`	⬆️
... and 109 files with indirect coverage changes

MelvinBot · 2026-05-23T03:34:47Z

Updated the PR body to use the latest checklist template and checked off all items. The previous version was missing several checklist items (CSS styles, assets, markdown, generic components, Storybook, deeplinks, UI modifications, ScrollView).

MelvinBot · 2026-05-23T03:41:39Z

Regression Analysis: Group Chat & Split Bill

No regressions found for split bills or group chats. The refactored loaded-report path is logically equivalent to the old code. The fallback is strictly additive (shows PAY where previously nothing was shown). Two items to be aware of:

Split Bills — Safe

Split bills create IOU SPLIT actions on the group chat, not REPORT_PREVIEW actions (Split.ts:495-503). Since getIOUReportActionWithBadge only processes REPORT_PREVIEW actions (line 337), the fallback path is never reached for split group chats. The 1:1 DM REPORT_PREVIEW actions created per split participant are standard IOUs and handled correctly.

Group Chats — Safe (with known limitation)

Group chats can have multiple REPORT_PREVIEW actions (one per IOU/expense report). The fallback only matches the one whose childReportID === chatReport.iouReportID, and iouReportID tracks the latest IOU (MoneyRequestBuilder.ts:464, PayMoneyRequest.ts:549-550). This means older outstanding IOUs won't get a fallback badge — but this is a temporary state (once reports load from Onyx, the full getBadgeFromIOUReport path handles all IOUs correctly).

Missing: Archived Chat Check

⚠️ The isArchivedReport check was reportedly added but is not present in the current branch. canPayIOUFromReportAction at line 314 does not check for archived chats, and the corresponding unit test is also missing. This means an archived chat with an outstanding p2p IOU could briefly show a PAY badge via the fallback until the IOU report loads. This should be addressed before merge.

aimane-chnaif · 2026-05-23T07:12:33Z

@MelvinBot mark as ready for review

MelvinBot · 2026-05-23T07:13:47Z

Marked the PR as ready for review.

MelvinBot assigned aimane-chnaif May 22, 2026

MelvinBot requested a review from a team May 22, 2026 18:04

MelvinBot mentioned this pull request May 22, 2026

Action Badge: Diagnose GBR display bugs — phantom GBR and missing action badge until click #86897

Open

aimane-chnaif reviewed May 22, 2026

View reviewed changes

Refactor: early-return when iouReport is missing to skip getBadgeFrom…

e995c5a

…IOUReport Co-authored-by: Aimane Chnaif <aimane-chnaif@users.noreply.github.com>

aimane-chnaif reviewed May 23, 2026

View reviewed changes

Conversation

MelvinBot commented May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

This comment was marked as resolved.

Uh oh!

aimane-chnaif May 22, 2026

Choose a reason for hiding this comment

Uh oh!

MelvinBot May 22, 2026

Choose a reason for hiding this comment

Uh oh!

MelvinBot commented May 22, 2026

Uh oh!

MelvinBot commented May 22, 2026

Uh oh!

aimane-chnaif commented May 22, 2026

Uh oh!

MelvinBot commented May 22, 2026

Code Review

Uh oh!

chatgpt-codex-connector Bot commented May 22, 2026

Uh oh!

aimane-chnaif commented May 22, 2026

Uh oh!

MelvinBot commented May 22, 2026

Uh oh!

MelvinBot commented May 22, 2026

Regression Analysis

Uh oh!

aimane-chnaif commented May 23, 2026

Uh oh!

MelvinBot commented May 23, 2026

Uh oh!

This comment was marked as resolved.

Uh oh!

MelvinBot commented May 23, 2026

Uh oh!

aimane-chnaif commented May 23, 2026

Uh oh!

MelvinBot commented May 23, 2026

Uh oh!

MelvinBot commented May 23, 2026

Uh oh!

aimane-chnaif commented May 23, 2026

Uh oh!

codecov Bot commented May 23, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

MelvinBot commented May 23, 2026

Uh oh!

MelvinBot commented May 23, 2026

Regression Analysis: Group Chat & Split Bill

Split Bills — Safe

Group Chats — Safe (with known limitation)

Missing: Archived Chat Check

Uh oh!

aimane-chnaif commented May 23, 2026

Uh oh!

MelvinBot commented May 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

MelvinBot commented May 22, 2026 •

edited

Loading

codecov Bot commented May 23, 2026 •

edited by github-actions Bot

Loading