Expense - Retracted message with RBR does not appear in expense report when retracting fails

[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.7-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-3292/folder/13176741/41237131/1143583571, #78634
Email or phone of affected tester (no customers): sjodijnojnsojsndioo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 26.1 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Open the expense report.
5. Click Submit.
6. Open test tool modal via CMD+D.
7. Enable "Simulate failing network requests".
8. Close the modal.
9. Click More > Retract.

Expected Result:

"retracted" message with RBR error "Unexpected error. Please try again later." will appear in the expense report.

Actual Result:

"retracted" message with RBR error "Unexpected error. Please try again later." does not appear in the expense report.
"retracted" message appears briefly then disappears.

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

[melvin-bot]

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

[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: #78634 - "new Onyx Derived Value VISIBLE_REPORT_ACTIONS" by @BartekObudzinski (High confidence)
Related Issues: None

Recommendation: REVERT

PR #78634 introduced a performance optimization that pre-computes report action visibility using a derived value. However, this optimization breaks the visibility logic for actions that fail with errors, causing the retracted message with RBR error to disappear instead of remaining visible.

Labels: Keeping DeployBlockerCash (App deploy blocked); Removing DeployBlocker if present (not a backend issue)

📋 Detailed Analysis

Evidence

The bug reproduces when retracting a report with simulated failing network requests. The "retracted" message appears briefly then disappears, instead of remaining visible with the RBR error message.

PR #78634 was merged on 2026-01-22 and is included in the 9.3.7-1 staging deploy. The issue was reported in regression testing and is reproducible only on staging (where this PR is deployed), not production (where it is not yet deployed).

Verification

I examined the changes in PR #78634 and confirmed it modifies the exact code path responsible for filtering visible report actions in MoneyRequestReportActionsList.tsx:

BEFORE PR #78634:

shouldReportActionBeVisible(reportAction, reportAction.reportActionID, canPerformWriteAction) &&
...

This called shouldReportActionBeVisible at RUNTIME for each action.

AFTER PR #78634:

const isStaticallyVisible = visibleReportActionsData?.[actionReportID]?.[reportAction.reportActionID] ?? true;
if (!isStaticallyVisible) {
    return false;
}

This uses a PRE-COMPUTED derived value that caches visibility.

Root Cause

When retractReport is called:

1. An optimistic RETRACTED action is added with pendingAction: ADD (line 9958 in src/libs/actions/IOU/index.ts)
2. The derived value computes and caches this action as visible
3. When the API call fails, failureData adds errors to the action (line 10030-10032)
4. However, the failureData does NOT set pendingAction: null, leaving the action in a state with both pendingAction: ADD and errors

The issue is that the derived value (src/libs/actions/OnyxDerived/configs/visibleReportActions.ts) caches visibility based on shouldReportActionBeVisible, which checks for pendingAction at line 1116 of ReportActionsUtils.ts:

return !!reportAction.pendingAction || !isDeletedAction(reportAction) || ...

The problem appears to be a timing or state management issue where the cached visibility value doesn't properly reflect the runtime state when an action has both a pending action and errors, particularly in offline/simulated failure scenarios.

The old code called shouldReportActionBeVisible on every render with the current action state, but the new code relies on a cached value that may not update correctly for this edge case.