Expense - Transaction thread is blank when quickly opening expense after splitting

[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.7-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: https://github.com/Expensify/Acpp/pull/78634
Email or phone of affected tester (no customers): sodijnosijdsojsonsji@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
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.
5. Click More > Split > Save.
6. Quickly open any split.

Expected Result:

Transaction thread will be visible.

Actual Result:

Transaction thread is blank when quickly opening expense after splitting.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7056031_1769127591175.11_cnKSzfjI.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @brianlee-expensify (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.

[melvin-bot]

Triggered auto assignment to @srikarparsi (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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 #78634 new Onyx Derived Value VISIBLE_REPORT_ACTIONS by BartekObudzinski High confidence. Recommendation REVERT. PR #78634 introduced a derived value to pre-compute report action visibility creating a timing issue when quickly opening transaction threads after splitting expenses. The derived value computation may not complete before the transaction thread is opened resulting in a blank thread. Labels No changes needed both DeployBlockerCash and DeployBlocker should remain as this is a frontend bug. Evidence: PR #78634 merged 2026-01-22 bug reported 2026-01-23 version 9.3.7-0 reproducible on staging NOT production. PR #78634 in StagingDeployCash #80277. Bug symptoms match timing issue. Verification: PR #78634 modifies ReportActionsView.tsx changing visibleReportActions filtering from calling shouldReportActionBeVisible directly to checking pre-computed derived value. Root Cause: When splitting and quickly opening transaction thread the derived value computation may not finish before navigation causing visibleReportActions to be empty resulting in blank thread.

[OSBotify]

Detailed Analysis:

Affected file: src/pages/home/report/ReportActionsView.tsx

Changes in PR #78634:
The PR changed how visible report actions are filtered. Previously it called shouldReportActionBeVisible() directly during filtering. Now it checks a pre-computed derived value visibleReportActionsData.

The Race Condition:

1. User splits an expense - transaction thread reports are created optimistically
2. VISIBLE_REPORT_ACTIONS derived value computation starts
3. User QUICKLY opens a split transaction thread (before computation completes)
4. visibleReportActionsData for the new thread is incomplete/not populated
5. visibleReportActions becomes empty array
6. Transaction thread renders blank

Why previous code worked: Called shouldReportActionBeVisible() synchronously during filter so it always had current visibility state even for newly created threads.

Recommendation: REVERT PR #78634 to unblock deploy then investigate proper fix with better handling for optimistic transaction threads.