[Due for payment 2026-09-09] Spend - Paid by column does not immediately show the payer after paying the report on Spend

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.65-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: #98326
Email or phone of affected tester (no customers): sdsiodjnosdjiodsj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Create an expense in workspace chat.
3. Go to Spend > Reports.
4. Click Display > Edit columns.
5. Select Paid by and click Save.
6. Click Submit, Approve and Mark as paid on the report row.

Expected Result:

Paid by column will show the payer after paying the report on Spend.

Actual Result:

Paid by column does not show the payer after paying the report on Spend.
It only shows the payer after reopening Spend and reapplying the filter.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7247561_1788204361514.5.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7247561

Issue Owner

Current Issue Owner: @hoangzinh

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/ea7f7a154451919400fe1dc5472a4bb205cc16e868779b3950bf924ff8a80a57

[melvin-bot]

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

[melvin-bot]

@JS00001 @hoangzinh you have been assigned to this deploy blocker because you reviewed the offending PR: #98326

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

@c3024 you have been assigned to this deploy blocker because you authored the offending PR: #98326

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #98326 - "Add Paid by search filter UI, table column, sorting, and export" by @c3024 (High confidence)
Related Issues: None found

Recommendation: ROLL FORWARD

The Paid by column is derived exclusively from the search snapshot's REIMBURSED-family report actions, so it can never populate optimistically — the action the App writes when you pay is an IOU/pay action that only lands in the live report actions collection. The targeted fix is ~10 lines mirroring the firstApprover column's existing live-merge pattern, which is far safer than reverting a 34-file PR that also regenerates both Peggy parsers and touches 11 language files.

Assigned: @c3024 (PR author), @JS00001 and @hoangzinh (approving reviewers) from #98326 — already assigned by melvin-bot, confirmed correct.
Labels: No changes. DeployBlockerCash is kept (an App PR caused this). DeployBlocker was not present and was not added.

📋 Detailed Analysis

Evidence

• PR [Payment due @hoangzinh] Add Paid by search filter UI, table column, sorting, and export #98326 merged 2026-08-31T18:12:05Z; this issue was filed 2026-08-31T19:40:58Z on 9.4.65-0. [Payment due @hoangzinh] Add Paid by search filter UI, table column, sorting, and export #98326 is on the 9.4.65-0 checklist.
• The PR diff introduces the entire Paid by column pipeline that this bug is about: lastReimbursedActionByReportID, the isReportPaid gate, and the paidByAccountID / formattedPaidBy row fields. Nothing about this column existed before it.
• Checked every other PR on the staging checklist for changes to SearchUIUtils.ts / Search / PayMoneyRequest.ts. The only other staging PR that touches src/libs/SearchUIUtils.ts is #99080, which is a Button prop-cleanup refactor and is unrelated to the payer column or to optimistic-update logic. No other candidate.
• Not reproducible in production, correctly, because the column does not exist there. The symptom is purely client-side: the value appears after "reopening Spend and reapplying the filter", i.e. after a fresh Search API response repopulates the snapshot. That is the signature of a missing optimistic path, not a backend problem.

Verification

Affected file: src/libs/SearchUIUtils.ts.

• The bug site, added by [Payment due @hoangzinh] Add Paid by search filter UI, table column, sorting, and export #98326: SearchUIUtils.ts#L3148-L3152
• The snapshot map that feeds it, also added by [Payment due @hoangzinh] Add Paid by search filter UI, table column, sorting, and export #98326: SearchUIUtils.ts#L1862 and SearchUIUtils.ts#L1899-L1910
• The pre-existing, correct pattern for the sibling column: getFirstApprovedAction, called at #L3140

gh pr view 98326 --json files confirms src/libs/SearchUIUtils.ts is in the PR, and the diff hunks land exactly on the lines above.

Root Cause

There are two independent defects, both of which have to be fixed for the column to update immediately.

1. The column reads the snapshot only, never the live report actions.

At #L3149 the payer is read straight out of the precomputed snapshot map:

const lastReimbursedAction = lastReimbursedActionByReportID.get(reportItem.reportID);
const paidByAccountID = lastReimbursedAction?.actorAccountID;

Compare the firstApprover column three lines above, which seeds the snapshot value into a scan over the live actions from getLiveOrSnapshotReportActions:

const firstApprovedAction = getFirstApprovedAction(firstApprovedActionByReportID.get(reportItem.reportID), actions);

The reason this matters is documented in the file itself at #L2982-L2986: "snapshot merges only keep fields already present in the snapshot shape, so a new optimistic action never reaches it." An optimistic action is a brand-new key, so it lands in reportActions_<reportID> but never in the snapshot. That is why the report's status badge flips to Paid immediately (statusNum is an existing snapshot field, so the merge lands) while Paid by stays blank.

2. Even with the live actions merged in, the action-name filter would still miss the payment.

The map only accepts REIMBURSED, MARKEDREIMBURSED and ACTIONMARKEDREIMBURSEDFROMINTEGRATION. But paying from Spend goes through payMoneyRequest, whose optimistic action is built by buildOptimisticIOUReportAction with type: CONST.IOU.REPORT_ACTION_TYPE.PAY, which produces actionName: CONST.REPORT.ACTIONS.TYPE.IOU — not a REIMBURSED action. The REIMBURSED action is created server-side and is in fact hidden from the chat UI precisely because the IOU/pay action stands in for it (ReportActionsUtils.ts#L1340-L1346). So the App has no locally-created REIMBURSED action to find, at any point before the next Search response.

Secondarily, the isReportPaid guard at #L1862 keys off the snapshot report's statusNum, adding a third ordering dependency on snapshot state for a value that should be derivable from the actions alone.

Suggested fix (roll forward)

Mirror the approver pattern with a getLastPaidAction(snapshotReimbursedAction, actions) helper built on the existing findActionByCreated(..., 'latest', seed), and have it accept the optimistic payment too:

• Seed with lastReimbursedActionByReportID.get(reportItem.reportID) and scan the live actions already computed at #L3117.
• Include the REIMBURSED family and IOU actions whose originalMessage.type === CONST.IOU.REPORT_ACTION_TYPE.PAY, taking actorAccountID as the payer (buildOptimisticIOUReportAction sets it to the current user, which is the payer).
• Keep the paid-only gate, but evaluate it against the report item in getSections rather than the snapshot-time isReportPaid flag, so an optimistically-paid report qualifies.

Worth adding a unit test in tests/unit/Search/SearchUIUtilsTest.ts that feeds a snapshot with no REIMBURSED action plus a live optimistic IOU/pay action and asserts formattedPaidBy is populated.

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: CONSISTENCY-19 Derive Search Columns From Live Report Actions, Not The Snapshot Alone
• Condition: When a Search table column in src/libs/SearchUIUtils.ts is derived from report actions, never read the precomputed *ActionByReportID snapshot map directly. Pass it as the seed argument of findActionByCreated over getLiveOrSnapshotReportActions(...), and make sure the action-name list includes the action the App actually writes optimistically for that flow.
• Why: Snapshot merges only update keys already present in the snapshot shape, so an optimistic report action never reaches the snapshot. A snapshot-only column stays blank until the next Search response, which reads to users as a broken column. This is the mechanism behind [Due for payment 2026-09-09] Spend - Paid by column does not immediately show the payer after paying the report on Spend #99968, where Paid by stayed empty after paying from Spend.
• Search pattern: grep -n "ActionByReportID\.get(" src/libs/SearchUIUtils.ts — flag any hit whose result is consumed directly instead of being passed as the seed argument to findActionByCreated.
• Offending code (❌): SearchUIUtils.ts#L3148-L3152
• Fix (✅): the existing correct shape one column up — SearchUIUtils.ts#L3140 and getFirstApprovedAction

The full rule file, with the ❌/✅ code inline in Expensify/App's coding-standards format, would go in Expensify/App itself (.claude/skills/coding-standards/rules/consistency-19-*.md plus the SKILL.md bullet). If it's worth adding, a maintainer can open it there as a draft PR.