[$250] Report - "Waiting for you to fix the issue" briefly visible after adding expense with receipt

[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.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: #85225
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.

1. Open the staging.new.expensify.com website.
2. Open any workspace chat.
3. Create a manual expense.
4. Open the report of the just created expense.
5. Click on "Add a receipt" and add a receipt to expense.
6. Return to chat.
7. Create an empty report and open it.
8. Click on "Add Expense" > "Add existing expense"
9. Select the expense with receipt and add it to report.
10. Note that next step message on report shows "Waiting for you to fix the issue" briefly, despite no error being displayed.

Expected Result:

"Waiting for you to fix the issue" next step message, should not appear if added expense doesn´t have any violation or error.

Actual Result:

"Waiting for you to fix the issue" next step message is briefly visible after adding an existing expense with receipt to report. Message is displayed despite expense not having any violation or error.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abzokhattab

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022050259461311956348
• Upwork Job ID: 2050259461311956348
• Last Price Increase: 2026-05-01

[melvin-bot]

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

[melvin-bot]

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

[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: #85225 - "Feat: Change Add unreported expense to Add existing expense in a report" by @nyomanjyotisa (High confidence)
Related Issues: N/A

Recommendation: REVERT

PR #85225 is the clear cause of this staging-only regression. The bug is not present in production (the feature doesn't exist there yet), and the causing PR can be cleanly reverted.

Assigned: @nyomanjyotisa (PR author), @puneetlath (approving reviewer)
Labels: DeployBlockerCash retained (Frontend bug — App PR caused the issue). DeployBlocker is not present and should not be added.

Detailed Analysis

Evidence

• melvin-bot identified PR Feat: Change Add unreported expense to Add existing expense in a report #85225 as the causing PR in the first comment on this issue.
• The issue is marked "Reproducible in production: N/A - new feature, doesn't exist in prod", confirming this regression was introduced by PR Feat: Change Add unreported expense to Add existing expense in a report #85225 which is only on staging.
• PR Feat: Change Add unreported expense to Add existing expense in a report #85225 was merged on 2026-04-29 and is listed in the StagingDeployCash for version 9.3.65-0.
• The bug involves the "Add existing expense" flow, which is exactly what PR Feat: Change Add unreported expense to Add existing expense in a report #85225 added/modified (it renamed "Add unreported expense" to "Add existing expense" and expanded the eligible transactions to include expenses from open draft reports, not just unreported ones).

Verification

• PR Feat: Change Add unreported expense to Add existing expense in a report #85225 modifies src/pages/AddExistingExpense.tsx (renamed from AddUnreportedExpense.tsx) and src/components/AddExistingExpenseFooter.tsx.
• The key behavioral change is in getEligibleTransactions: previously only transactions with reportID === CONST.REPORT.UNREPORTED_REPORT_ID || reportID === '' were eligible. PR Feat: Change Add unreported expense to Add existing expense in a report #85225 expanded this to also include transactions on any open expense report (using the new openExpenseReportIDsSelector).
• The footer's handleConfirm calls changeTransactionsReport when moving expenses. That function, in section 9 ("Update next steps"), calls ViolationsUtils.getViolationsOnyxData for the moved transaction in the context of the destination report's policy.
• When a receipt-bearing expense is moved from a draft/open report, the violation computation may produce violations (e.g., required fields not yet met in the destination report's policy context), setting shouldFixViolations = true.
• This causes buildNextStepNew to optimistically generate a "Waiting for you to fix the issue" next step on the destination report. The message clears once the server responds with the correct state.

Root Cause

The violation-computation logic in changeTransactionsReport (lines 1152–1178 of src/libs/actions/Transaction.ts) runs ViolationsUtils.getViolationsOnyxData for each incoming transaction. For a draft-report expense being moved to a new report, this may produce violations optimistically (based on the destination policy's rules) and set shouldFixViolations = true. The resulting next-step computation then shows "Waiting for you to fix the issue" on the destination report's banner—even though the expense has no actual violations—until the server response clears the optimistic state.

This code path was never exercised before PR #85225 because the old "Add unreported expense" flow only allowed moving truly unreported transactions (with no reportID), which took a different branch in changeTransactionsReport (the isUnreported path that clears violations rather than computing them).

[MelvinBot]

Proposal

What is the root cause of that problem?

When adding an existing expense to a report via changeTransactionsReport, the client optimistically computes violations for the moved transaction using ViolationsUtils.getViolationsOnyxData. If the workspace policy requires categories or tags and the transaction doesn't have them set, policy violations like missingCategory are generated client-side. This sets shouldFixViolations = true in Transaction.ts:1178-1179, which causes buildOptimisticNextStep to produce a WAITING_TO_FIX_ISSUES next step at NextStepUtils.ts:131-137.

This optimistic next step is pushed to Onyx immediately, causing the "Waiting for you to fix the issues" message to render. When the server responds with the real next step (which doesn't include the fix-issues message since there are no actual blocking violations), the message disappears — producing the brief flash.

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

The shouldFixViolations flag in changeTransactionsReport should not be set to true for policy violations like missingCategory or missingTag when the transaction is being moved via "Add existing expense". These violations are informational and don't warrant the "fix the issues" next step message.

Two possible approaches:

1. Filter out non-blocking violations when computing shouldFixViolations — only set it to true for violations that genuinely block submission (like SMARTSCAN_FAILED or NO_ROUTE), matching the logic already used in hasSubmissionBlockingViolations.

2. Skip the optimistic next step computation for the shouldFixViolations path when handling the "add existing expense" flow, since the server will compute the correct next step.

Approach 1 is preferred as it addresses the root cause and keeps optimistic updates accurate.

Investigation details

Data flow of the bug:

1. User selects existing expense with receipt → changeTransactionsReport() fires
2. ViolationsUtils.getViolationsOnyxData() generates optimistic violations (e.g., missingCategory if workspace requires categories)
3. shouldFixViolations set to true because non-duplicate violations exist
4. buildOptimisticNextStep() produces WAITING_TO_FIX_ISSUES next step
5. Optimistic data pushed to Onyx → useOptimisticNextStep hook re-renders → flash appears
6. Server responds with correct next step → flash disappears

Key observation: The render-time path in getReportNextStep (NextStepUtils.ts:357-375) already correctly limits the "fix issues" check to only SMARTSCAN_FAILED and NO_ROUTE violations via hasSubmissionBlockingViolations. The optimistic path in changeTransactionsReport should follow the same pattern.

---

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.