[Due for payment 2026-03-19] Expense - Submit button appears again after clicking it

[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.36-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: #83424
Email or phone of affected tester (no customers): biruknew45+yyyu@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Web, android
App Component: Money Requests

Action Performed:

Precondition -
WS must have Report fields

1. Go to https://staging.new.expensify.com/
2. Go to Workspace chat
3. Create an expense
4. Go to another chat and return if the expense preview doesn't appear
5. Click on the submit button

Expected Result:

Submit button shouldn't reappear

Actual Result:

Submit button reappears

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7100498_1773268179985.bandicam_2026-03-12_01-26-41-713.mp4

View all open jobs on GitHub

[melvin-bot]

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

[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: #83424 - "fix: GBR appears when there is report field error" by @daledah (High confidence)
Related Issues: None

Recommendation: REVERT

PR #83424 introduced a logic inconsistency that causes the submit button to reappear after submission when there are missing required report fields. The PR added report field violation checks to the visual indicator (Red Brick Road) but did not add corresponding checks to the submission logic, creating a mismatch between UI state and business logic.

Labels: This is a frontend bug caused by an App PR. The issue is reproducible on staging but not production (as stated in the issue), which confirms it was introduced in this staging deployment. I am removing the DeployBlocker label as this is a frontend-specific issue.

📋 Detailed Analysis

Evidence

PR #83424 was merged on 2026-03-11 at 18:57:58Z and is included in the 9.3.36-0 staging deploy. The melvin-bot comment in the issue explicitly identifies this PR as the cause.

The bug reproduces when:

1. Workspace has Report Fields enabled
2. A required report field exists
3. User creates an expense and clicks submit
4. After submission, the submit button reappears

Root Cause

PR #83424 made the following changes:

1. Added hasVisibleReportFieldViolations function (src/libs/ReportUtils.ts lines 13061-13089):

   • This function checks if a report has any visible report field violations
   • It uses getFieldViolation() which returns FIELD_REQUIRED when a required report field has no value (line 12315-12322)

2. Modified the Red Brick Road (RBR) calculation (src/libs/actions/OnyxDerived/configs/reportAttributes.ts lines 202-220):

   • Changed: hasAnyViolations → hasAnyViolations || hasFieldViolations
   • This makes the RBR indicator appear when report fields are missing

The bug: The PR added report field violations to the visual RBR indicator but did NOT add them to the canSubmit function in src/libs/ReportPreviewActionUtils.ts.

Looking at canSubmit (ReportPreviewActionUtils.ts line 54):

if (transactions?.some((transaction) => hasSubmissionBlockingViolations(transaction, violations, currentUserEmail, currentUserAccountID, report, policy))) {
    return false;
}

The hasSubmissionBlockingViolations function only checks for transaction-level violations (SMARTSCAN_FAILED and NO_ROUTE), not report-level field violations.

What happens:

1. User clicks submit → expense is submitted successfully
2. After submission, the expense still has missing report fields
3. hasVisibleReportFieldViolations returns true → RBR shows
4. Since RBR is showing and canSubmit does not check report field violations, the submit button reappears
5. This creates an infinite loop where the button can be clicked repeatedly

Verification

Files affected by the bug:

• /home/runner/_work/App/App/src/libs/ReportUtils.ts - Added hasVisibleReportFieldViolations function
• /home/runner/_work/App/App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts - Modified RBR calculation
• /home/runner/_work/App/App/src/libs/ReportPreviewActionUtils.ts - Missing corresponding change to canSubmit

The PR modifies exactly these areas and the timing matches (merged on 2026-03-11, issue reported for staging 9.3.36-0).