[Due for payment 2026-09-16] [$250] Expenses are approved and unheld without confirmation when report contains all held expenses

[mitarachim]

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

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create two expenses.
4. Open the expense report.
5. Hold both expenses.
6. Go back to workspace chat.
7. Click Submit button.
8. Click Approve button.

Expected Result:

Confirmation modal will show up because report contains held expenses.

Actual Result:

There is no confirmation modal when report contains held expenses.
The report is approved directly and expenses are unheld without confirmation.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7086420_1771884482463.3.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @jjcoffee

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022026073828833618166
• Upwork Job ID: 2026073828833618166
• Last Price Increase: 2026-02-23
• Automatic offers:
• mkzie2 | Contributor | 110567566

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @stephanieelliott (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[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: #70825 - "Clarify Approval Options When Held Expenses Exist" by @mkzie2 (High confidence)
Related Issues: N/A

Recommendation: REVERT

PR #70825 introduced a regression where the confirmation modal is no longer shown when approving reports that contain ALL held expenses. The PR attempted to clarify approval options by creating a new ExpenseHeaderApprovalButton component, but the logic incorrectly skips the confirmation modal when hasOnlyHeldExpenses = true.

Labels: Keeping DeployBlockerCash (App PR caused the issue), will remove DeployBlocker (not a backend issue)

📋 Detailed Analysis

Evidence

The bug is reproducible only on staging (v9.3.25-0) and not in production, and PR #70825 was merged in this staging release. The reproduction steps exactly match the scenario this PR was designed to handle (held expenses during approval).

Verification

Files affected by the bug:

• /home/runner/_work/App/App/src/components/ExpenseHeaderApprovalButton.tsx (new file created in PR Clarify Approval Options When Held Expenses Exist #70825)
• /home/runner/_work/App/App/src/components/MoneyReportHeader.tsx (modified to use new component)

Confirmation that PR #70825 modified these files:
The PR diff shows it created ExpenseHeaderApprovalButton.tsx and refactored the approval logic in MoneyReportHeader.tsx to use this new component.

Root Cause

Before PR #70825:
When approving a report with held expenses, the code would set isHoldMenuVisible(true) to show the ProcessMoneyReportHoldMenu confirmation modal for ALL cases where isAnyTransactionOnHold === true.

After PR #70825:
The new ExpenseHeaderApprovalButton component has flawed logic at line 122:

if (approvalOptions.length > 1) {
    return <ButtonWithDropdownMenu ... />
}
// Falls through to simple Button without confirmation
return <Button onPress={() => onApprove(true)} ... />

The problem is in getApprovalDropdownOptions() (lines 73-81):

if (nonHeldAmount && hasValidNonHeldAmount && !hasOnlyHeldExpenses) {
    options.push({ /* partial approval option */ });
}
options.push({ /* full approval option */ });

When hasOnlyHeldExpenses = true:

• Only the full approval option is added
• approvalOptions.length = 1
• The condition approvalOptions.length > 1 is false
• A simple Button is rendered instead of the dropdown
• This Button directly calls onApprove(true) without any confirmation modal

The old code would always show a confirmation modal when isAnyTransactionOnHold was true, regardless of whether some or all expenses were held.