Repository navigation
[Due for payment 2026-04-02] Android - Expense - After navigating back from the Workspace Chat, the “Not here” page appears #85408
Description
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.38-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: #84656
Email or phone of affected tester (no customers): biruknew45+78hjs@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: android
App Component: Money Requests
Action Performed:
- https://staging.new.expensify.com/
- Go to a workspace chat
- Create an expense
- Open it
- Click More > Split > Save
- Open any split
- Click Report > Create report
- On the remaining expense, click Amount
- Click on the highlighted row
- Click Remove split
- Click Save
- After it navigates you to WS chat click on Back navigation
Expected Result:
Not here page shouldn't appear, back navigation should navigate to the correct page
Actual Result:
After navigating back from the Workspace Chat, the “Not here” page appears, and navigating back again opens WS chat again, and navigating again opens WS settings page.
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
Issue Owner
Current Issue Owner: @abzokhattabMetadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
melvin-bot commentedon Mar 16, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #84656
melvin-bot commentedon Mar 16, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Mar 16, 2026
👋 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:
OSBotify commentedon Mar 16, 2026
🔍 Investigation Summary
Classification: Frontend bug
Causing PR: #84656 - "Fix Not Here page after removing split expense" by @MelvinBot (High confidence)
Related Issues: #84612 (the issue #84656 was trying to fix)
Recommendation: ROLL FORWARD
PR #84656 attempted to fix a "Not here" page issue when removing split expenses, and it successfully fixed the initial navigation. However, it introduced a new regression: when users navigate back AFTER being taken to the workspace chat, they encounter a "Not here" page. This suggests that while #84656 correctly navigates to the parent chat report when the expense report is deleted, it does not fully clean up the navigation stack.
The issue is staging-only (not reproducible in production), confirming this is caused by PR #84656 which is only on staging.
A revert would reintroduce the original bug from #84612. Instead, the fix should enhance the navigation stack cleanup in
updateSplitTransactionsFromSplitExpensesFlowto remove all intermediate screens that reference the deleted expense report, not just the transaction thread.Labels: Keeping
DeployBlockerCash(App deploy blocked - this is a frontend bug requiring App code changes)📋 Detailed Analysis
Evidence
The reproduction steps in this issue are nearly identical to the test steps in PR #84656, with one critical addition: step 12 - "click on Back navigation" after being taken to the workspace chat. This extra back navigation triggers the "Not here" page.
PR #84656 test steps end with: "Verify the expense report RHP closes and navigates to the workspace chat without showing Not here page" ✅ This works.
Issue #85408 adds: "After it navigates you to WS chat click on Back navigation" → "Not here page appears" ❌ This fails.
Verification
The affected code is in
/home/runner/_work/App/App/src/libs/actions/IOU/Split.ts, specifically theupdateSplitTransactionsFromSplitExpensesFlowfunction (lines 1694-1763).PR #84656 modified this function to:
setDeleteTransactionNavigateBackUrlto suppress "Not here" during transition (line 1712)However, it only removes the
transactionThreadReportScreenand does not clean up other screens in the navigation stack that may reference the now-deleted expense report (such as the split expense detail screens or the expense report detail screen itself).Root Cause
When
updateSplitTransactionsFromSplitExpensesFlowperforms a reverse split that deletes the expense report:dismissModalWithReportrequestAnimationFrameReportScreenshows "Not here" pageThe fix in PR #84656 was incomplete - it addressed the immediate navigation but did not fully clean up the navigation history.
MelvinBot commentedon Mar 16, 2026
Proposal
Please re-state the problem that we are trying to solve in this issue.
On Android, after splitting an expense, creating a report from one split, removing the remaining split (triggering a reverse-split), and saving, the user is navigated to the Workspace Chat. However, pressing the hardware Back button from the WS chat shows a "Not here" page instead of normal back navigation. Further back presses create a loop between the WS chat and the "Not here" page.
This is a regression introduced by #84656, which was supposed to fix the same "Not here" page issue but introduced an incomplete navigation stack cleanup.
What is the root cause of that problem?
The root cause is that
updateSplitTransactionsFromSplitExpensesFlowinsrc/libs/actions/IOU/Split.tsleaves a stale expense report screen in the navigation back stack after a reverse-split deletes the expense report. Here's the sequence:The function correctly calls
setDeleteTransactionNavigateBackUrlto temporarily suppress the "Not here" page, and then callsdismissModalWithReport({reportID: parentChatReportID}).On Android (narrow layout),
dismissModalWithReportcallsnavigate(reportRoute, {forceReplace: true})(src/libs/Navigation/Navigation.ts:773). Since the RHP (split expense page) is the focused root-level route, the REPLACE action operates at the root level -- it replaces the RHP with a newReportsSplitNavigatorcontaining the WS chat, while the oldReportsSplitNavigator(containing the now-deleted expense report screen) remains in the back stack.The code then only removes the transaction thread report screen via
removeScreenByKey(Split.ts:1756-1762), but does not remove the expense report screen from the old SplitNavigator.DeleteTransactionNavigateBackHandler(src/pages/inbox/DeleteTransactionNavigateBackHandler.tsx:18-31) clears thedeleteTransactionNavigateBackUrlvia a deferred callback when the old expense report screen loses focus.When the user presses Back, the new SplitNavigator (single route, no sidebar on narrow layout) pops entirely, revealing the old SplitNavigator with the stale expense report screen. Since
deleteTransactionNavigateBackUrlis already cleared and the report'sreportIDwas set tonullby the optimistic deletion,shouldShowNotFoundPage(src/pages/inbox/ReportScreen.tsx:511-554) returnstrue, showing the "Not here" page.What changes do you think we should make in order to solve the problem?
In
updateSplitTransactionsFromSplitExpensesFlow(src/libs/actions/IOU/Split.ts), whenisLastTransactionInReportis true, the expense report screen should also be removed from the navigation stack afterdismissModalWithReportcompletes, alongside the existing transaction thread screen removal.The approach should follow the pattern used by other deletion flows (e.g.,
MoneyReportHeader,MoneyRequestHeader): instead of usingdismissModalWithReport(which pushes forward and leaves stale entries), first dismiss the RHP, then navigate back past the expense report screen to the parent chat. This ensures the deleted report's screen is naturally removed from the back stack rather than lingering.Alternatively, after
dismissModalWithReport, look up the expense report screen viaNavigation.getReportRouteByID(expenseReportID)and explicitly remove it -- though this would require enhancingremoveScreenByKeyorremoveReportScreento handle screens nested inside SplitNavigators (currently they only filter root-level routes).What alternative solutions did you explore? (Optional)
deleteTransactionNavigateBackUrlset longer: This would only mask the symptom. The stale screen would still be in the navigation stack, and clearing the URL at any point would expose the "Not here" page again.Navigation.removeReportScreen(new Set([expenseReportID]))after navigation: This existing utility only operates on root-level routes and would miss nested screens inside SplitNavigators on narrow layout.Next Steps for Contributor+ team: Reply with
@MelvinBot implement thisto create a draft PR,@MelvinBot <your feedback>to refine this analysis, or explain why you are rejecting Melvin's proposal.Valforte commentedon Mar 16, 2026
@abzokhattab can you take a look and see if you can whip up a quick fix for this bug? If so we can CP it.
abzokhattab commentedon Mar 16, 2026
@MelvinBot implement this
MelvinBot commentedon Mar 16, 2026
🤖 Draft PR created: #85425
Please mark it as "Ready for review" when it is ready for review.
cristipaval commentedon Mar 17, 2026
I think this can be demoted; it isn't worse than the original bug that was fixed by the offending PR, and it is a rare use case that doesn't block the user from using the feature
11 remaining items
melvin-bot commentedon Mar 26, 2026
Reviewinglabel has been removed, please complete the "BugZero Checklist".melvin-bot commentedon Mar 26, 2026
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.3.48-2 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-04-02. 🎊
melvin-bot commentedon Mar 26, 2026
@Valforte The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
melvin-bot commentedon Mar 26, 2026
Triggered auto assignment to @mallenexpensify (
Awaiting Payment)mallenexpensify commentedon Apr 2, 2026
Payment Summary
Contributor+: @abzokhattab due $250 via NewDot
quinthar commentedon Apr 13, 2026
Approved $250 to @abzokhattab