[Due for payment 2026-04-23] [Due for payment 2026-04-20] Report - Held expense is automatically unheld after bulk approving report.

@Krishna2323

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.58-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: #85796
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Prerequisite: Account has at least one workspace.
Prerequisite 2: Delayed submissions, approvals and payments enabled.

Open the Expensify app.
Open workspace chat,
Create three manual expenses.
Open the expenses report.
Long tap and select one of the expenses.
Tap on dropdown menu > "Hold"
Enter any reason and save.
Select all the expenses on report.
Tap on dropdown menu and select "Submit"
Select all the expenses again.
Tap on dropdown menu > "Approve"
Note that all the expenses, included the held one, are automatically approved.
Open the held expense.
Note that "Unheld this expenses" message is displayed.

Expected Result:

Hold modal should appear when trying to approve report with held expenses. Held expenses shouldn´t be automatically approved.

Actual Result:

Held expenses are automatically approved and unheld after bulk approving report. "Hold" modal is not displayed.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Krishna2323

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

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

👋 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:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

@Krishna2323

Investigation Summary

Classification: Frontend bug
Causing PR: #85796 - "Add selection mode Submit/Approve/Pay actions for mobile layout." by @Krishna2323 (High confidence)
Related Issues: #72502 (the issue this PR fixed)

Recommendation: REVERT

PR #85796 introduced the new selection-mode Submit/Approve/Pay actions for the mobile layout. The hold modal is not being shown when approving a report with held expenses via this new selection mode path, causing held expenses to be automatically approved and unheld. The PR is the direct cause and should be reverted until the hold modal integration in the selection mode flow is fixed.

Assigned: @Krishna2323 (PR author), @situchan (approving reviewer), @puneetlath (approving reviewer)
Labels: No label changes - DeployBlockerCash is correct and stays. This is a frontend (App) bug caused by an App PR.

Detailed Analysis

Evidence

The issue body explicitly links PR Add selection mode Submit/Approve/Pay actions for mobile layout. #85796 as the related PR, and melvin-bot assigned the PR author in the first comment
PR Add selection mode Submit/Approve/Pay actions for mobile layout. #85796 was merged on 2026-04-09 and is included in the StagingDeployCash checklist (version 9.3.58-0/1)
The bug is staging-only ("Reproducible in production?: N/A - new feature, does not exist in prod"), confirming it was introduced by this staging PR
The PR introduced the useSelectionModeReportActions hook and wired it into MoneyRequestReportActionsList.tsx for mobile selection mode approve/submit/pay

Verification

Affected files: src/hooks/useSelectionModeReportActions.ts (new file, added by this PR) and src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx (modified by this PR)
PR Add selection mode Submit/Approve/Pay actions for mobile layout. #85796 directly modifies both files and introduces the selection mode approve flow

Root Cause

In src/hooks/useSelectionModeReportActions.ts, the confirmApproval() function checks isAnyTransactionOnHold before calling setIsHoldMenuVisible(true). The ProcessMoneyReportHoldMenu is rendered in MoneyRequestReportActionsList.tsx and is gated on isHoldMenuVisible && requestType !== undefined. Despite the logic appearing structurally correct, the hold modal is not being shown in practice on Android HybridApp when approving through the selection mode dropdown. The handleHoldMenuConfirm callback only clears selections and exits selection mode - the actual approveMoneyRequest call is supposed to be executed inside useHoldMenuSubmit (called via ProcessMoneyReportHoldMenu) when the user confirms in the modal. Since the modal never appears, the approval path falls through directly to approveMoneyRequest without the hold gate, unheld the held expense automatically.

Proposal

What is the root cause of that problem?

The selection-mode approve path in useSelectionModeReportActions.ts calls setIsHoldMenuVisible(true) synchronously inside confirmApproval() (line 315). This state update fires while the ButtonWithDropdownMenu popover is still dismissing its animation, causing the ProcessMoneyReportHoldMenu modal (a DecisionModal) to fail to appear on Android.

The payment path already has a fix for this exact issue on iOS — it defers the state update using InteractionManager.runAfterInteractions (lines 351-354):

if (getPlatform() === CONST.PLATFORM.IOS) {
    InteractionManager.runAfterInteractions(() => setIsHoldMenuVisible(true));
} else {
    setIsHoldMenuVisible(true);
}

The approve path is missing this deferral entirely, and the popover/modal conflict also affects Android (the existing iOS-only fix in the payment path may be insufficient for Android as well).

Because the hold menu never visually appears, the user's tap on "Approve" falls through to approveMoneyRequest with full: true, which approves and unholds all expenses.

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

Apply the same InteractionManager.runAfterInteractions deferral to confirmApproval() in useSelectionModeReportActions.ts (line 315). The deferral should apply on both iOS and Android (not just iOS as the payment path currently does), since the popover dismiss animation conflicts with modal presentation on both platforms.

Additionally, the existing payment path's iOS-only guard should be extended to also cover Android, for the same reason.

What alternative solutions did you explore?

An alternative is to add a small setTimeout delay before showing the hold menu, but InteractionManager.runAfterInteractions is the idiomatic React Native approach and is already used in the adjacent payment path.

Another alternative is to restructure the dropdown to wait for its popover close animation to complete before firing onSelected, but that would be a larger change with wider impact.

Investigation details

Relevant code locations:

src/hooks/useSelectionModeReportActions.ts:310-335 — confirmApproval() missing deferral
src/hooks/useSelectionModeReportActions.ts:349-357 — confirmPayment() with iOS-only deferral (reference for the fix)
src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx:1053-1069 — ProcessMoneyReportHoldMenu rendering
src/components/ProcessMoneyReportHoldMenu.tsx — DecisionModal wrapper

Evidence chain:

User selects all expenses and taps Approve from the selection mode dropdown
handleApproveSelected() → confirmApproval() fires synchronously
isAnyTransactionOnHold correctly evaluates to true (via hasHeldExpensesReportUtils at line 153)
setIsHoldMenuVisible(true) fires synchronously (line 315) — no deferral
The ProcessMoneyReportHoldMenu (DecisionModal) attempts to mount while the ButtonWithDropdownMenu popover is still animating closed
On Android, the modal fails to present — the user never sees it
Since the hold menu was "shown" (state-wise) but never confirmed, no approval action fires from the hold menu. However, if the modal fails to mount entirely and the state cleanup doesn't happen, it's possible the approval proceeds directly.

Alternative explanation considered: Stale transaction data causing isAnyTransactionOnHold to return false. This was ruled out — hasHeldExpensesReportUtils reads from getReportTransactions which uses deprecatedReportsTransactions (Onyx data), and the held status (transaction.comment.hold) persists through submit. The hold check logic is identical to the working non-selection-mode path in useConfirmApproval.ts.

Possibly related issue: #78130 — Hold educational modal displayed incorrectly on Reports in selection mode.

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.

Working on the PR.

It's unclear to me whether this is resolved or not

Resolved

Confirm approval amount modal displayed

This is expected result

Reviewing label has been removed, please complete the "BugZero Checklist".

@Krishna2323

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.3.58-9 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

Fix held expenses auto-approved without hold modal in selection mode #87651

If no regressions arise, payment will be issued on 2026-04-20. 🎊

For reference, here are some details about the assignees on this issue:

@Krishna2323 requires payment through NewDot Manual Requests
@situchan requires payment through NewDot Manual Requests

@Krishna2323

@Krishna2323 / @situchan The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

@Krishna2323

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.3.59-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

Fix held expenses auto-approved without hold modal in selection mode #87651

If no regressions arise, payment will be issued on 2026-04-23. 🎊

For reference, here are some details about the assignees on this issue:

@Krishna2323 requires payment through NewDot Manual Requests
@situchan requires payment through NewDot Manual Requests

@Krishna2323

@Krishna2323 / @situchan The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

Navigation Menu

Repository navigation

[Due for payment 2026-04-23] [Due for payment 2026-04-20] Report - Held expense is automatically unheld after bulk approving report. #87644

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Investigation Summary

Recommendation: REVERT

Evidence

Verification

Root Cause

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore?

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Due for payment 2026-04-23] [Due for payment 2026-04-20] Report - Held expense is automatically unheld after bulk approving report. #87644

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

melvin-bot commented on Apr 10, 2026

melvin-bot commented on Apr 10, 2026

github-actions commented on Apr 10, 2026

OSBotify commented on Apr 10, 2026

Investigation Summary

Recommendation: REVERT

Evidence

Verification

Root Cause

MelvinBot commented on Apr 10, 2026

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore?

Krishna2323 commented on Apr 10, 2026

1 remaining item

roryabraham commented on Apr 10, 2026

situchan commented on Apr 11, 2026

melvin-bot commented on Apr 13, 2026

melvin-bot commented on Apr 13, 2026

melvin-bot commented on Apr 13, 2026

melvin-bot commented on Apr 16, 2026

melvin-bot commented on Apr 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions