[Due for payment 2026-05-07] Spend - Empty state screen displayed for some seconds after splitting an expense.

[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.62-5
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-22585/folder/13176791/41237172/1371128335?q=split&issue_type=jira
#85234
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: Search

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. Navigate to "Spend" > "All Expenses"
5. Select the just created expense.
6. Click on dropdown menu and select "Split"
7. Save splits amount.
8. Note that after returning to "All Expenses", empty state screen appears for some seconds before splits are displayed.

Expected Result:

Splits should appear automatically on "All Expenses" after user splits an expense.

Actual Result:

After splitting an expense while on "All Expenses" on "Spend", empty state screen is displayed for some seconds before the new splits appear.

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: @ZhenjaHorbach

[melvin-bot]

Triggered auto assignment to @arosiclair (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: #85234 - "Introduce a Bottom Tab Navigator for Top-Level Navigation" by @WojtekBoman (High confidence)
Related Issues: #85260 (original issue this PR fixed)

Recommendation: REVERT

PR #85234 introduced a fundamental navigation architecture change (a true createBottomTabNavigator replacing individual root-stack screens). The freezeOnBlur: true and lazy: true options on the new TabNavigator cause the Search tab to get frozen when a modal (the Split expense flow) is pushed onto the root stack. When the user returns to the Search tab ("All Expenses"), the tab briefly unfreezes and re-evaluates its state before the newly-created splits are reflected by Onyx, producing the flash of the empty state.

Assigned: @WojtekBoman (PR author), @ZhenjaHorbach @mountiny (approving reviewers)
Labels: DeployBlockerCash kept (frontend bug, no label changes needed — DeployBlocker was not present)

Detailed Analysis

Evidence

• The issue body itself directly links PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 as the causing PR.
• The bug is reproducible on staging but not production, which aligns with PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 being merged on 2026-04-24 and included in the 9.3.62-5 staging build (entry 124 in the StagingDeployCash chronological list).
• The bug affects the Search tab ("All Expenses") after performing a split expense action that opens a modal, which is exactly the interaction path most affected by the new tab navigator's freeze-on-blur behavior.

Verification

• Affected area: src/libs/Navigation/AppNavigator/Navigators/SearchFullscreenNavigator.tsx, src/libs/Navigation/AppNavigator/Navigators/TabNavigator.native.tsx, src/libs/Navigation/AppNavigator/FreezeWrapper/index.native.tsx
• Confirmed PR modifies these files: PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 modifies SearchFullscreenNavigator.tsx (changes its parent type from AuthScreensParamList to TabNavigatorParamList and wraps it in FreezeWrapper), introduces TabNavigator.native.tsx with freezeOnBlur: true and lazy: true, and changes FreezeWrapper/index.native.tsx to a no-op (deferring to react-native-screens native freeze).

Root Cause

Before PR #85234, the SearchFullscreenNavigator was an independent screen pushed directly onto the root stack. After this PR, it lives as a tab inside a createBottomTabNavigator with freezeOnBlur: true. When a user is on the Search tab and opens the Split expense modal (which pushes onto the root/RightModal stack), the Search tab is no longer "focused" from the tab navigator's perspective. Upon modal dismissal and return to the Search tab, react-native-screens briefly unfreezes the tab, which triggers a re-render of the search page. During this re-render, the Onyx search results have not yet fully updated to reflect the newly-created splits, causing the empty state to appear momentarily before the data hydrates. This race between the tab unfreeze and Onyx data propagation is the root cause of the flash.