[$250] [Merge Expenses] "Not Here" page briefly flashes when navigating back to workspace chat after merging with a self-DM expense

[MelvinBot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Reproducible in staging?: Yes
Reproducible in production?: Needs validation
Issue reported by: Applause Internal Team (QA) — split out from #79416
Bug source: Exploratory
Device used: iOS: App
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com.
2. Create an expense in self DM.
3. Create an expense in a workspace chat.
4. Open the expense report in the workspace chat.
5. Tap More > Merge.
6. Select the self DM expense > Continue.
7. Select all the details from the self DM expense (second option in each section) > Next.
8. Tap Merge expenses.
9. After being redirected to Self-DM, tap the Back arrow to return to the workspace chat.

Expected Result:

The user is navigated back to the workspace chat and the chat loads normally, without any intermediate error state.

Actual Result:

The "Not Here" (not found) page briefly flashes before the workspace chat loads.

Platforms:

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

Screenshots/Videos

A recording of this flash was captured during KI retesting on #79416 — see this comment.

Context

This bug was split out of #79416. The original issue reported infinite skeleton loading when navigating back to the workspace chat after merging an expense with a self-DM expense. That infinite-loading symptom is no longer reproducible, but fixing it surfaced a separate, smaller regression: a brief flash of the "Not Here" page on the way back to the workspace chat. Per discussion on #79416, this is related but distinct and is being tracked here as its own issue.

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022062349940166452805
• Upwork Job ID: 2062349940166452805
• Last Price Increase: 2026-06-04

[MelvinBot]

Proposal

What is the root cause of that problem?

Merging an expense optimistically deletes an expense report (sets the Onyx report to null), but the merge flow never sets the NVP_DELETE_TRANSACTION_NAVIGATE_BACK_URL guard that the app uses everywhere else to hide the "Not Here" page while navigating back to a just-deleted report. So when you tap Back into that deleted report, the not-found guard fires for one frame before navigation/data settles.

In this flow the surviving merged expense lands in the Self-DM (mergeTransaction.reportID), and because that differs from the original report the workspace expense report's transaction is the one removed. When its report holds a single transaction, the merge nulls the whole report:

Evidence

• The merge optimistically sets the deletable report to null when it has one transaction: MergeTransaction.ts:442-453.
• After merge, navigation dismisses to the destination (Self-DM) report: ConfirmationPage.tsx:95-109. Tapping Back returns to the now-null workspace report.
• The not-found guard shows the page when the report is missing and loading is done — unless deleteTransactionNavigateBackUrl is set: ReportNotFoundGuard.tsx:53 (shouldShowNotFoundPage = !deleteTransactionNavigateBackUrl && (...)).
• That NVP is precisely the anti-flash mechanism — see the handler comment: DeleteTransactionNavigateBackHandler.tsx:26 ("Clear the URL only after we navigate away to avoid a brief Not Found flash.").
• The dedicated delete-transaction flow sets it before navigating back: DynamicReportDetailsPage.tsx:1020-1024. A grep confirms no call to setDeleteTransactionNavigateBackUrl anywhere in MergeTransaction.ts or src/pages/TransactionMerge/.

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

When the merge optimistically deletes a report (the transactionsOfDeletableReport.length === 1 case in MergeTransaction.ts), have the merge flow set NVP_DELETE_TRANSACTION_NAVIGATE_BACK_URL to the correct back destination (the surviving/destination report, or the deleted report's parent chat) before navigating away in ConfirmationPage.handleMergeExpenses, mirroring what DynamicReportDetailsPage.tsx:1020-1024 already does for deletes. The existing DeleteTransactionNavigateBackHandler then clears it once navigation settles, so the guard is suppressed for the back transition and the workspace chat loads without the flash.

What alternative solutions did you explore? (Optional)

Adding a short loading grace period in ReportNotFoundGuard would also hide the flash, but it would mask the symptom globally rather than reuse the existing, purpose-built guard, and risks delaying genuine not-found cases.

Related issues

• Expensify/App#79416 — parent issue (infinite-loading symptom; this flash was split out of it).
• Expensify/App#86817 — "Not here page appears after merging expenses offline & tapping back button." Same root cause; offline the report is never re-fetched so the page sticks instead of flashing. Likely fixable together.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92607) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @abzokhattab (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022062349940166452805

[ReaperOAK]

Proposal

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

After merging a workspace expense with a self-DM expense, tapping Back from the self-DM briefly renders a "Not Here" (NotFoundPage) before the workspace chat loads. This one-frame error state should never be visible.

What is the root cause of that problem?

The merge flow optimistically nulls the workspace expense report in Onyx (when that report held only the one transaction being merged away), then navigates to the self-DM — but never sets the NVP_DELETE_TRANSACTION_NAVIGATE_BACK_URL guard that the rest of the app uses to suppress the NotFound flash when navigating back to a just-deleted report.

Exact locations:

1. src/libs/actions/MergeTransaction.ts ~lines 442–453
When the source report contains only the transaction being merged, the optimistic update sets that report to null in Onyx:

// optimistically deletes the workspace expense report when it held only one transaction
{
    onyxMethod: Onyx.METHOD.SET,
    key: `${ONYXKEYS.COLLECTION.REPORT}${sourceReportID}`,
    value: null,
}

This is the correct behavior — but it leaves ReportNotFoundGuard with a null report and no suppression signal.

2. src/pages/inbox/ReportNotFoundGuard.tsx ~line 53

const shouldShowNotFoundPage = !deleteTransactionNavigateBackUrl && (isReportNotFound && !isLoading);

The guard renders NotFoundPage when the report is null/missing AND loading is complete, unless deleteTransactionNavigateBackUrl is set. The merge flow never sets this NVP.

3. src/pages/inbox/DeleteTransactionNavigateBackHandler.tsx ~line 26
Comment explicitly states the NVP's purpose: "Clear the URL only after we navigate away to avoid a brief Not Found flash." The handler navigates to the NVP URL then clears it.

4. src/pages/DynamicReportDetailsPage.tsx ~lines 1020–1024
The established pattern: before navigating away after a delete, call setDeleteTransactionNavigateBackUrl with the parent workspace chat report URL (not the IOU/expense report). The DeleteTransactionNavigateBackHandler then navigates there and clears the NVP.

5. src/pages/TransactionMerge/ConfirmationPage.tsx ~lines 95–109
After merge, navigates to the self-DM. Never calls setDeleteTransactionNavigateBackUrl. This is the missing call.

Data flow of the bug:

1. User is in the workspace expense report (IOU report, sourceReportID)
2. Merges → MergeTransaction.ts optimistically sets report[sourceReportID] = null
3. Navigation goes to self-DM
4. User taps Back → router renders workspace expense report route
5. Onyx has report[sourceReportID] = null, isLoading = false
6. ReportNotFoundGuard evaluates shouldShowNotFoundPage = true → NotFoundPage renders for one frame
7. Server response eventually rehydrates (or navigation settles) and the correct page loads

Why the target URL must be the workspace chat report, not the expense report:
DeleteTransactionNavigateBackHandler navigates to the stored URL and then clears the NVP. If we store the URL of the now-deleted expense report itself, we'd loop back into the same null-report problem. The pattern in DynamicReportDetailsPage.tsx stores the parent chat (chatReport) so the handler can navigate to a report that actually exists. In this merge scenario the equivalent is the workspace chat report that is the parent of the source IOU report — retrievable via ReportUtils.getReport(sourceReport.parentReportID) or equivalent.

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

File: src/pages/TransactionMerge/ConfirmationPage.tsx

Before dispatching the merge (or immediately before the Navigation.dismissModal call

[github-actions]

⚠️ @ReaperOAK Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[aswin-s]

Proposal

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

On iOS, after merging a workspace-chat expense with a self-DM expense, the user lands on the self-DM and taps the back arrow to return to the workspace chat. The "Not Here" page briefly flashes before the workspace chat renders. Expected: the workspace chat loads cleanly without any intermediate not-found state.

What is the root cause of that problem?

During the merge, mergeTransactionRequest in src/libs/actions/MergeTransaction.ts:442-455 optimistically deletes the target expense report (the workspace-chat expense report) by setting report/<reportID> to null when it is a single-transaction report. When the user navigates back, ReportNotFoundGuard in src/pages/inbox/ReportNotFoundGuard.tsx:53 sees reportExists === false while isLoading === false, so shouldShowNotFoundPage evaluates true and the not-found UI flashes until the parent workspace chat finishes resolving. The standard single-expense delete flow avoids this by calling setDeleteTransactionNavigateBackUrl (see src/pages/DynamicReportDetailsPage.tsx:1023), which the guard explicitly treats as an escape hatch in the !deleteTransactionNavigateBackUrl && … check on line 53. The merge flow never sets that NVP, so the guard has no signal that the deletion is an in-flight, user-initiated cleanup.

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

1. In src/pages/TransactionMerge/ConfirmationPage.tsx around handleMergeExpenses (lines 69–114), before triggering navigation back, call setDeleteTransactionNavigateBackUrl from @userActions/Report with the URL of the screen we are returning the user to (the self-DM chat / reportIDToDismiss) whenever the optimistic merge will delete a report (i.e. when the deletable report has a single transaction).
2. Mirror the existing single-expense delete pattern used in src/pages/DynamicReportDetailsPage.tsx:1023 so ReportNotFoundGuard short-circuits via the existing !deleteTransactionNavigateBackUrl branch on src/pages/inbox/ReportNotFoundGuard.tsx:53 and the deleted-report screen does not flash "Not Here".
3. Rely on the existing DeleteTransactionNavigateBackHandler (src/pages/inbox/DeleteTransactionNavigateBackHandler.tsx) to clear the NVP once the user finishes navigating, so no new teardown code is needed and the SEARCH / RHP branches in handleMergeExpenses are unaffected.
4. Apply the same set in the search branch (line 100) and the dismissToSuperWideRHP branch (line 113) only when the optimistic data actually deleted a report — gate on transactionsOfDeletableReport.length === 1 semantics by exposing a small return value from mergeTransactionRequest (or computing the same condition in the caller via getReportTransactions) so we don't set the NVP when no report was deleted.

What alternative solutions did you explore? (Optional)

Tightening ReportNotFoundGuard to also treat report === null (just-deleted) as "optimistic delete" was considered, but the guard intentionally distinguishes statusNum === CLOSED (optimistic close) from hard-null reports, and broadening it would regress genuine not-found cases; piggybacking on the existing NVP is the narrower, consistent fix.

[moxw]

The implementation distinction I’d make here is that the deleted expense report must not remain as the self-DM’s back target; this needs stack/back-target cleanup in addition to the existing delete-navigation guard.

Proposal

What is the root cause of that problem?

During merge, mergeTransactionRequest() chooses a transactionToDelete based on the destination report:

const transactionToDelete = mergeTransaction.reportID === targetTransaction.reportID ? sourceTransaction : targetTransaction;

In this repro, the user starts from the workspace expense report, selects the self-DM expense/details, and the merged expense is moved to the self-DM report. Since the destination is not the target transaction’s current report, the workspace expense becomes transactionToDelete.

When that workspace expense report only contains this one transaction, MergeTransaction.ts optimistically sets that report to null. That is correct data cleanup, but ConfirmationPage then navigates to the self-DM with Navigation.dismissModalWithReport({reportID: reportIDToDismiss}), leaving the now-deleted workspace expense report in the report stack/back history.

When the user taps Back from the self-DM, React Navigation briefly focuses that deleted expense report route. ReportNotFoundGuard sees the report is missing and NVP_DELETE_TRANSACTION_NAVIGATE_BACK_URL is unset, so it renders the “Not Here” page for a frame before ReportNavigateAwayHandler redirects to the parent workspace chat.

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

In the merge confirmation flow, detect the same report-deletion case before applying the optimistic merge:

• Determine transactionToDelete with the same condition used in MergeTransaction.ts.
• Get its report and transaction count.
• If that report will be emptied, compute the stable fallback report as the deleted expense report’s parent workspace chat, e.g. deletableReport.chatReportID ?? deletableReport.parentReportID.
• Set setDeleteTransactionNavigateBackUrl(ROUTES.REPORT_WITH_ID.getRoute(fallbackReportID)) before mergeTransactionRequest() applies the optimistic report = null update.

Then make the self-DM redirect avoid using the deleted expense report as the Back target:

• When navigating to the surviving destination report with dismissModalWithReport, pass backTo as the fallback workspace chat route when the current/deletable report was removed.
• Also remove the deleted report screen from navigation state after the modal dismissal, using the same stale-report cleanup pattern already used in split/reverse-split flows (Navigation.getReportRouteByID(...).key + Navigation.removeScreenByKey(...)).

This preserves the intended redirect to self-DM after merge, but tapping Back from self-DM goes directly to the workspace chat instead of briefly landing on the deleted expense report.

Tests should cover:

• Workspace expense report with one transaction merged into a self-DM destination: sets the delete navigate-back URL to the workspace chat and navigates to self-DM with that workspace chat as backTo.
• Workspace expense report with multiple transactions: does not set the delete guard or remove the report route.
• Same-report merge where the current report is not deleted: existing navigation remains unchanged.

What alternative solutions did you explore? (Optional)

A global delay or loading grace period in ReportNotFoundGuard would hide the flash, but it would weaken real not-found behavior. Only suppressing via NVP_DELETE_TRANSACTION_NAVIGATE_BACK_URL is also incomplete if the deleted report remains in the back stack and the guard is cleared before the user taps Back. The fix should target the merge-specific deleted-report navigation state.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-04 02:04:10 UTC.

Proposal

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

After merging a workspace expense with a self-DM expense, the app redirects to the self-DM. When the user then taps Back, the workspace chat eventually opens, but the deleted/intermediate money-request report can briefly render the "Hmm... it's not here" page first.

What is the root cause of that problem?

The merge flow opens the destination report without preserving the valid back target from the original expense report.

On narrow layouts, opening a workspace expense report from a workspace chat stores the current workspace-chat route as backTo on the expense route. During merge confirmation, however, when the selected destination differs from the target expense's original report, ConfirmationPage calls Navigation.dismissModalWithReport({reportID: reportIDToDismiss}) with only the destination report ID.

At the same time, the merge makes the original workspace expense route stale. In this self-DM source flow, selecting the self-DM/unreported destination stores the merge destination as CONST.REPORT.UNREPORTED_REPORT_ID, and the target transaction is updated through the track/self-DM merge path. The cross-report merge data also moves the surviving transaction away from the original report, reparents the target transaction thread, and removes the old IOU action from the original workspace expense report. Once the server/Onyx sync removes or empties that original single-expense report, the previous route is no longer a valid screen.

So after the self-DM report opens, its route has no explicit backTo. The header Back button falls through to plain Navigation.goBack(), which exposes the previous workspace expense report route still in the stack. That report has just been removed from Onyx, so ReportNotFoundGuard shows Not Here for a frame. Then ReportNavigateAwayHandler detects the deleted report and navigates to its parent workspace chat, which is why the correct chat appears after the flash.

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

Update the cross-report merge navigation in src/pages/TransactionMerge/ConfirmationPage.tsx so the destination report is opened with the valid parent workspace-chat back route when the original target report is being removed.

Concretely:

1. Before navigating after mergeTransactionRequest(), detect the stale-route case: the merge destination differs from targetTransaction.reportID, and the target's original report is a single-transaction workspace expense report that will no longer be a valid Back destination after the merge sync.
2. Derive the valid back target from targetTransactionReport?.chatReportID ?? targetTransactionReport?.parentReportID, and build ROUTES.REPORT_WITH_ID.getRoute(parentChatReportID).
3. Open the destination report with that backTo route, e.g. by passing {reportID: reportIDToDismiss, backTo: parentChatRoute} into dismissModalWithReport, or preferably by using Navigation.revealRouteBeforeDismissingModal(ROUTES.REPORT_WITH_ID.getRoute(reportIDToDismiss, undefined, undefined, parentChatRoute)) for the RHP dismissal path so the deleted report is never revealed under the modal.
4. Keep ReportNotFoundGuard unchanged. It is correctly protecting genuinely missing reports; this merge flow should avoid navigating back through a report it already knows it removed.

This keeps the normal same-report merge behavior intact, and it also avoids removing arbitrary report screens from navigation state when the original report still has other expenses and should remain a valid Back target.

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

Add a focused test for the merge confirmation navigation helper/path where the target is a workspace expense report, the source is a self-DM/unreported expense, and the selected destination is the self-DM. Verify the destination route includes backTo pointing at the original workspace chat, and that the stale target expense report is not the next route reached by Back.

Also cover the non-regression case where the original target report has multiple transactions or the merge stays in the same report, so the existing report remains a valid Back destination.