Report - "Waiting for you to fix the issue" remains after adding category by multiple editing

[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: 9.3.21.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: #76264
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
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: Account has Self DM.

1. Open the Expensify app.
2. Open any workspace chat.
3. Create a manual expense.
4. Navigate to Self DM.
5. Create a manual expense without merchant and category.
6. Open the just created expense.
7. Tap on report field and move it to the report of expense created on step 3.
8. Navigate to the report of the two expenses.
9. Note that a "Waiting for you to fix the issues" next step message is displayed on top of report.
10. Select both expenses.
11. Tap on the dropdown menu and select "Edit Multiple"
12. Add any merchant and any category and save the editions.
13. Note that error messages disappear from second expense preview, but "Waiting for you to fix the issues" next step message is still visible.

Expected Result:

"Waiting for you to fix the issues" next step message should not be visible anymore after adding a merchant and category to an expense by editing multiple expenses.

Actual Result:

When adding a merchant and a category to an expense by multiple editing expenses, "Missing Merchant" and "Missing Category" errors disappear, but next step message still displays a "Waiting for you to fix the issues" message.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @marcaaron

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @greg-schroeder (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: #76264 - "Feat: bulk edit multiple" by @waterim (High confidence)
Related Issues: None identified

Recommendation: ROLL FORWARD

The issue is a race condition in the optimistic update logic when bulk editing multiple transactions. The fix is straightforward and safer than reverting the entire bulk edit feature.

Root Cause: When bulk editing multiple expenses, each transaction is updated individually via updateMultipleMoneyRequests. Each call to getUpdateMoneyRequestParams calculates whether the report still has violations by checking hasViolations(reportID, allTransactionViolations, ...). However, allTransactionViolations contains stale data for transactions that havent been processed yet in the loop. This causes the nextStep calculation to incorrectly detect violations still exist, keeping the "Waiting for you to fix the issues" message even after all violations are resolved.

Labels: No changes needed - correctly labeled as DeployBlockerCash only

📋 Detailed Analysis

Evidence

PR #76264 introduced the bulk edit feature and the updateMultipleMoneyRequests function (lines 14578-14608 in src/libs/actions/IOU/index.ts). The bot correctly identified this PR in the issue comments.

Verification

The bug manifests in the bulk edit flow:

1. File: /home/runner/_work/App/App/src/libs/actions/IOU/index.ts
2. Function: updateMultipleMoneyRequests (added in PR Feat: bulk edit multiple #76264)
3. The function loops through transactions and calls getUpdateMoneyRequestParams for each

Root Cause

In getUpdateMoneyRequestParams (line 4959):

const hasViolations = hasViolationsReportUtils(moneyRequestReport?.reportID, allTransactionViolations, currentUserAccountIDParam, currentUserEmailParam);

The hasViolations check uses allTransactionViolations from the Onyx cache, which is:

• Updated optimistically for the current transaction being processed
• Still contains OLD violations for other transactions in the same report that are being edited in the same bulk operation
• Results in the nextStep calculation seeing violations that are actually being fixed

The nextStep is then set based on this stale hasViolations value (lines 4960-4995), causing "Waiting for you to fix the issues" to persist even after the violations are resolved.

Fix Approach

The fix should recalculate hasViolations after applying the optimistic violation updates for all transactions in the bulk edit, or pass the updated violations context to avoid checking stale cache data. This is a localized fix in the bulk edit flow.