[Payment 2025-11-14] [BACK BUTTON] [$250] Report -Infinite skeleton loader when deleting just moved expense from report and going back

[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.1.65-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): ibellicotest+1033@gmail.com
Issue reported by: Applause Internal Team
Device used: Motorola MotoG60 - Android 12 - Chrome (mWeb - Hybrid App) / Windows 10 - Chrome
App Component: Money Requests

Action Performed:

Prerequisite: Account has at least one workspace created.
Prerequisite 2: Account has a Self DM.

1. Open the staging.new.expensify.com website.
2. Open any workspace chat.
3. Submit a manual expense to it.
4. Navigate to Self DM and submit a manual track expense to it.
5. Open the just created track expense.
6. Tap on the report field and select the report of the expense created on workspace chat.
7. Once redirected to report, long tap on the just moved expense and select it.
8. Delete the expense.
9. Tap on the back button on the top left corner.
10. Note that you are redirected to a page with an infinite skeleton loader.

Expected Result:

After deleting an expense that was moved to a report and tapping the back button, user should land on Self DM again, where the just moved expense, shouldn´t be displayed.

Actual Result:

After deleting an expense that was moved to a report and tapping on the back button, the user lands on a page with infinite skeleton loader instead of returning to Self DM. This behaviour is experienced on mWeb.
On Web and Android Hybrid app, when tapping on back button after deleting expense, the user lands on "it´s not here" page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6857629_1749697923697.Android.mp4

Bug6857629_1749697923691.mWeb.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021938321035344900301
• Upwork Job ID: 1938321035344900301
• Last Price Increase: 2025-08-12
• Automatic offers:
• QichenZhu | Reviewer | 108943129

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @inimaga

[melvin-bot]

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

[bernhardoj]

🚨 Edited by proposal-police: This proposal was edited at 2025-09-18 10:39:37 UTC.

Proposal

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

Not found page after going back from report after moving expense and then deleting it.

What is the root cause of that problem?

When we move an expense to a report, the expense transaction thread page is still in the stack,

App/src/pages/iou/request/step/IOURequestStepReport.tsx

Lines 39 to 41 in 04a715b

	if (isEditing) {
	Navigation.dismissModalWithReport({reportID: item.value});
	} else {

so it looks like this:
[expense transaction thread page, expense report]

After we remove the transaction, going back will show not found page.

The infinite loader is shown because shouldShowNotFoundPage is false.

App/src/pages/home/ReportScreen.tsx

Lines 453 to 458 in 8ff8c1d

	if (!wasReportAccessibleRef.current && !firstRenderRef.current && !reportID && !isOptimisticDelete && !reportMetadata?.isLoadingInitialReportActions && !userLeavingStatus) {
	// eslint-disable-next-line react-compiler/react-compiler
	return true;
	}
	return !!currentReportIDFormRoute && !isValidReportIDFromPath(currentReportIDFormRoute);

It should be true because the report doesn't exist anymore, but wasReportAccessibleRef is true. It was added in #33041 to prevent the not found page from showing briefly when deleting an expense.

However, after many changes, wasReportAccessibleRef doesn't do what it was initially made for. wasReportAccessibleRef now contains the value of whether the report is available or not.

App/src/pages/home/ReportScreen.tsx

Lines 327 to 333 in 8ff8c1d

	useEffect(() => {
	if (!report?.reportID) {
	wasReportAccessibleRef.current = false;
	return;
	}
	wasReportAccessibleRef.current = true;
	}, [report]);

But since it's a ref, it doesn't trigger a recalculation of shouldShowNotFoundPage. That's why we also use the interaction manager to delay the delete to prevent the not found page from showing briefly.

App/src/components/MoneyReportHeader.tsx

Lines 1060 to 1068 in 8ff8c1d

	// it's deleting transaction but not the report which leads to bug (that is actually also on staging)
	// Money request should be deleted when interactions are done, to not show the not found page before navigating to goBackRoute
	InteractionManager.runAfterInteractions(() => deleteMoneyRequest(transaction?.transactionID, requestParentReportAction));
	goBackRoute = getNavigationUrlOnMoneyRequestDelete(transaction.transactionID, requestParentReportAction, false);
	}
	if (goBackRoute) {
	Navigation.setNavigationActionToMicrotaskQueue(() => navigateOnDeleteExpense(goBackRoute));
	}

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

Since we want to be navigated back to the self DM instead of the deleted expense, we can remove the route from the stack. First, create a new util function called removeReportScreen.

Here is how it looks (very similar to removeScreenByKey, but instead of filtering it by key, we filter it by reportID).

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

Then, in useSelectedTransactionsActions, we call the removeReportScreen.

App/src/hooks/useSelectedTransactionsActions.ts

Lines 121 to 130 in 79f111b

	const deletedTransactionIDs: string[] = [];
	transactionsWithActions.forEach(({transactionID, action}) => {
	if (!action) {
	return;
	}
	deleteMoneyRequest(transactionID, action, duplicateTransactions, duplicateTransactionViolations, false, deletedTransactionIDs);
	deletedTransactionIDs.push(transactionID);
	});
	clearSelectedTransactions(true);

const deletedTransactionThreadReportIDs = new Set<string>();
transactionsWithActions.forEach(({transactionID, action}) => {
    ...
    if (action.childReportID) {
        deletedTransactionThreadReportIDs.add(action.childReportID);
    }
});
Navigation.removeReportScreen(deletedTransactionThreadReportIDs)

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

Instead of using dismissModalWithReport, we can dismiss the modal first and then use goBack so the transaction thread is replaced.

App/src/pages/iou/request/step/IOURequestStepReport.tsx

Lines 39 to 41 in 04a715b

	if (isEditing) {
	Navigation.dismissModalWithReport({reportID: item.value});
	} else {

if (isEditing) {
    Navigation.dismissModal();
    Navigation.isNavigationReady().then(() => Navigation.goBack(ROUTES.REPORT_WITH_ID.getRoute(item.value)));

(we need to use isNavigationReady promise since dismissModal is also wrapped in a promise, we can make dismissModal return the promise instead if needed)

[melvin-bot]

@strepanier03 Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

@strepanier03 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[melvin-bot]

@strepanier03 10 days overdue. Is anyone even seeing these? Hello?

[melvin-bot]

@strepanier03 12 days overdue. Walking. Toward. The. Light...

[melvin-bot]

@strepanier03 this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[strepanier03]

Working on testing this now.