[Due for payment 2026-03-19] Expense - Expense preview does not appear after creating expense when report field is present

[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.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): sdjoisdnjosdjnoisdj@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:

Precondition:

• Create a text type report field in workspace settings > Reports.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
   → Expense preview is missing.
4. Navigate to another chat, then go back to workspace chat.
5. Open the expense report.
   → Expense report is empty.
6. Navigate to another chat, then go back to workspace chat.
7. Open the expense report.
   → Expense report is now loaded.

Expected Result:

In Step 4, expense preview will appear instantly after creating expense.

Actual Result:

In Step 4, expense preview does not appear instantly after creating expense.
In Step 5, expense preview only appears after reopening workspace chat, but the report is empty.
In Step 7, expense report is loaded after reopening workspace chat.

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

[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: #82676 (original issue being fixed)

Recommendation: REVERT

PR #83424 introduced a critical bug that prevents expense previews from appearing when report fields are present. The code references an undefined variable allReportsViolations that does not exist in scope, causing the reportAttributes computation to fail or return incorrect results.

Labels: Keeping DeployBlockerCash (Frontend bug - App PR caused the issue)

📋 Detailed Analysis

Evidence

The bug is reproducible only on staging (not production) and appears after PR #83424 was merged. The issue specifically occurs when:

• A text-type report field is created in workspace settings
• An expense is created in the workspace
• The expense preview fails to appear
• The expense report appears empty on first open

Verification

Root Cause: PR #83424 modified /src/libs/actions/OnyxDerived/configs/reportAttributes.ts to call hasVisibleReportFieldViolations(report, policy) at line 206.

This function (defined in ReportUtils.ts at line 13067) contains the following code at line 13076:

const reportViolations = allReportsViolations?.[`${ONYXKEYS.COLLECTION.REPORT_VIOLATIONS}${report.reportID}`];

The Problem: The variable allReportsViolations is never defined or imported anywhere in ReportUtils.ts. It does not exist as:

• A global variable
• An imported value
• An Onyx connection
• A parameter passed to the function

Root Cause

When hasVisibleReportFieldViolations is called during reportAttributes computation, it attempts to access allReportsViolations?.[...] which evaluates to undefined?.[...], resulting in reportViolations being undefined.

While the optional chaining prevents a crash, this causes the function to operate incorrectly, likely returning false positives for field violations (since getFieldViolation returns FIELD_REQUIRED when violations is undefined but the field has no value).

Additionally, REPORT_VIOLATIONS is not included in the dependencies array for the reportAttributes derived config (line 63-75 of reportAttributes.ts), so even if the variable existed, the data would not be available during computation.

This causes the expense preview rendering logic to fail or produce incorrect brick road statuses, preventing expense previews from appearing properly.

[dangrous]

This should be fixed with #84952

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After creating an expense in a workspace chat that has a text-type report field configured, the expense preview does not appear. It takes multiple navigations away and back before the expense report fully loads.

What is the root cause of that problem?

The hasVisibleReportFieldViolations function added in PR #83424 references an undeclared variable allReportsViolations on line 13076 of src/libs/ReportUtils.ts:

const reportViolations = allReportsViolations?.[`${ONYXKEYS.COLLECTION.REPORT_VIOLATIONS}${report.reportID}`];

This variable is never declared anywhere in ReportUtils.ts (unlike allReports, allPolicies, etc. which are module-level variables connected via Onyx.connect). Accessing an undeclared variable in JavaScript throws a ReferenceError, even with optional chaining (?.).

This function is called from inside the reportAttributes derived value computation at line 206 of reportAttributes.ts. The derived value init() function in OnyxDerived/index.ts has no try-catch around the compute() call (line 80), so the ReferenceError propagates unhandled, crashing the entire reportAttributes computation.

The error only triggers when all of these conditions are met:

1. The workspace policy has areReportFieldsEnabled: true (i.e., report fields are configured)
2. The policy has a non-empty fieldList
3. The report is a paid group policy expense report or invoice report

This matches the reproduction steps exactly: the bug only appears when a report field is present.

When the computation crashes, ONYXKEYS.DERIVED.REPORT_ATTRIBUTES is never updated for the new expense report. Components like MoneyRequestReportPreviewContent that depend on this derived value cannot get the report name or attributes, causing the expense preview to not render properly.

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

Two changes are needed:

1. In src/libs/ReportUtils.ts: Modify hasVisibleReportFieldViolations to accept reportViolations as a parameter instead of referencing the undeclared allReportsViolations module-level variable. This is consistent with how other functions like getFieldViolation already accept violations as a parameter.

2. In src/libs/actions/OnyxDerived/configs/reportAttributes.ts: Since the reportAttributes config does not include ONYXKEYS.COLLECTION.REPORT_VIOLATIONS in its dependencies, the report violations data is not available in the compute function. Either:

   • (Option A) Add ONYXKEYS.COLLECTION.REPORT_VIOLATIONS to the dependencies array and pass it to the updated hasVisibleReportFieldViolations function, OR
   • (Option B) For now, simply pass undefined for the violations parameter (since getFieldViolation(undefined, field) correctly returns FIELD_REQUIRED for empty fields, which is the behavior the original PR intended).

What alternative solutions did you explore? (Optional)

An alternative would be to add an Onyx.connect for ONYXKEYS.COLLECTION.REPORT_VIOLATIONS at the top of ReportUtils.ts to populate an allReportsViolations module-level variable (matching the pattern of allReports, allPolicies, etc.). However, this is less ideal because the function is called from within the derived value config, which should use its own dependency data rather than module-level state to ensure consistency.

---

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.