Web - Expense - Not here page opens after switching tab and deleting expenses in Inbox

[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.1-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
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-2943/folder/13177029/41237798/1123995421
Email or phone of affected tester (no customers): sduidbshiusbhsiudhui@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 two expenses.
4. Open the expense report.
5. Go to Reports tab.
6. Go back to Inbox.
7. Select both expenses via checkbox.
8. Click dropdown button > Delete.
9. Delete the expenses.

Expected Result:

App will return to workspace chat.

Actual Result:

Not here page opens after switching tab and deleting expenses in Inbox.

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]

Triggered auto assignment to @greg-schroeder (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.

[annaweber830]

Proposal

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

When a user switches tabs and then goes back to Inbox and bulk-deletes multiple expenses, the app sometimes navigates to the “Not here” (NotFound) page instead of returning to a valid screen .

What is the root cause of that problem?

Bulk delete triggers useSelectedTransactionsActions.handleDeleteTransactions(), which calls Navigation.removeReportScreen() to remove deleted transaction thread report screens from the navigation stack.
Navigation.removeReportScreen()filters out all matching report routes, but then adjusts the navigation index by only -1 if any routes were removed. If multiple report routes are removed (common when deleting multiple expenses), this can leave the navigation state focused on an invalid/non-existent route, which then causes the app to render the NotFound/“Not here” page.

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

Update Navigation.removeReportScreen() so that after it removes report routes, it computes a correct new navigation index based on:

• How many removed routes were before the currently focused route, and
• Whether the currently focused route itself was removed
  Then clamp the index to the valid range for the new routes array. This ensures we never land on an invalid route after bulk-removing multiple report screens.
  

  App/src/libs/Navigation/Navigation.ts

  Lines 703 to 719 in 8f123f4

  	function removeReportScreen(reportIDSet: Set<string>) {
  	isNavigationReady().then(() => {
  	navigationRef.current?.dispatch((state) => {
  	const routes = state?.routes.filter((route) => {
  	if (route.name === SCREENS.REPORT && route.params && 'reportID' in route.params) {
  	return !reportIDSet.has(route.params?.reportID as string);
  	}
  	return true;
  	});
  	return CommonActions.reset({
  	...state,
  	routes,
  	index: routes.length < state.routes.length ? state.index - 1 : state.index,
  	});
  	});
  	});
  	}

function removeReportScreen(reportIDSet: Set<string>) {
    isNavigationReady().then(() => {
        navigationRef.current?.dispatch((state) => {
            const removedRouteIndices: number[] = [];
            const routes = state?.routes.filter((route, routeIndex) => {
                const shouldRemove =
                    route.name === SCREENS.REPORT &&
                    route.params &&
                    'reportID' in route.params &&
                    reportIDSet.has(route.params?.reportID as string);

                if (shouldRemove) {
                    removedRouteIndices.push(routeIndex);
                }

                return !shouldRemove;
            });

            const removedCount = removedRouteIndices.length;
            const hadRemovedRoutes = removedCount > 0;
            const removedBeforeFocusedRouteCount = removedRouteIndices.filter((routeIndex) => routeIndex < state.index).length;
            const wasFocusedRouteRemoved = removedRouteIndices.includes(state.index);

            const nextIndexUnclamped = hadRemovedRoutes
                ? state.index - removedBeforeFocusedRouteCount - (wasFocusedRouteRemoved ? 1 : 0)
                : state.index;

            const nextIndex = Math.max(0, Math.min(routes.length - 1, nextIndexUnclamped));
            return CommonActions.reset({
                ...state,
                routes,
                index: nextIndex,
            });
        });
    });
}

What alternative solutions did you explore? (Optional)

• Adding a post-delete “navigate back to Inbox/workspace chat” step from the bulk-delete flow. This is more behavior-changing and less generic than fixing the underlying navigation index calculation.
• Removing report screens one-by-one (multiple resets). This is more complex and still risks incorrect index updates; computing the correct index once is simpler and safer.

[MobileMage]

Proposal

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

After switching tabs and bulk-deleting expenses, the app shows "Not here" page instead of navigating somewhere valid.

What is the root cause of that problem?

In src/libs/Navigation/Navigation.ts, removeReportScreen assumes only one route is removed:

index: routes.length < state.routes.length ? state.index - 1 : state.index,

When bulk-deleting multiple expenses, multiple report screens get removed. Subtracting 1 isn't enough - the index ends up pointing at a non-existent route.

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

Track how many routes before the current index were removed, then adjust accordingly:

function removeReportScreen(reportIDSet: Set<string>) {
    isNavigationReady().then(() => {
        navigationRef.current?.dispatch((state) => {
            let removedBeforeCurrent = 0;
            
            const routes = state?.routes.filter((route, i) => {
                const shouldRemove = route.name === SCREENS.REPORT && 
                    route.params && 
                    'reportID' in route.params && 
                    reportIDSet.has(route.params?.reportID as string);
                    
                if (shouldRemove && i < state.index) {
                    removedBeforeCurrent++;
                }
                return !shouldRemove;
            });

            return CommonActions.reset({
                ...state,
                routes,
                index: Math.max(0, Math.min(state.index - removedBeforeCurrent, routes.length - 1)),
            });
        });
    });
}

The key insight: we only need to track routes removed before the current index. The Math.min(..., routes.length - 1) clamp handles the case where the current route itself was removed.

What alternative solutions did you explore? (Optional)

Could track all removed indices and compute separately whether the focused route was removed, but that's more code for the same result. Counting removals before current index + clamping handles all cases.