Expense disappears from the report view before the thread screen is closed

[applause-bot]

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.89-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #88538
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: MacBook Air 26.5 Chrome
App Component: Money Requests

Action Performed:

1. Create a new expense report with two expenses
2. Navigate to the Spend/ Reports and open the report
3. Click on one of the expenses to enter its transaction thread
4. Inside the transaction thread, tap More → Delete
5. Observe the report view while the transaction thread screen closes
6. Create a new expense report with two expenses
7. Navigate to the Spend/ Reports and open the report
8. Tap the More button - Delete
9. Observe the screen while the report is closing

Expected Result:

Step 5 - The transaction thread screen closes first, and only then the transaction entry disappears from the report view (the entry should not vanish while the transaction thread is still animating closed)
Step 9 - The report entry in Spend is removed only after the report screen has fully closed (the entry should remain visible during the closing transition and disappear afterward)

Actual Result:

Step 5 -The transaction entry disappears while the thread is animating closed
Step 9 - The report disappears from the screen while the report view is closing

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7165846_1780008223260.Report_disappears.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7165846

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/59025b2bf075abfd3ade0cdccbda39bcc036cbb58b8bf3b436e057cf88390e1b

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #88538

[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.

[MelvinBot]

Proposal

What is the root cause of that problem?

This is a regression from #88538 (merged 2026-05-28), which migrated InteractionManager.runAfterInteractions cleanup patterns to Navigation.goBack({afterTransition: ...}) / TransitionTracker.runAfterTransitions. Two distinct bugs explain the two reported symptoms.

Step 5 — transaction-thread delete drops the row early (high confidence):
The DELETE handler in useExpenseActions was only half-migrated. The single-transaction branch still calls Navigation.goBack(...) synchronously and then wraps the Onyx mutation in the old InteractionManager.runAfterInteractions(...), so the close animation and the optimistic delete race (useExpenseActions.ts:521-538). The sibling whole-report branch in the same file was migrated correctly to Navigation.goBack(backToRoute, {afterTransition: () => deleteAppReport(...)}) (useExpenseActions.ts:557-572), so the new pattern is clearly what was intended. A telling smell: the file carries an // eslint-disable-next-line no-restricted-imports for InteractionManager (useExpenseActions.ts:5-6) — the lint rule installed by the migration is flagging this exact line.

Step 9 — whole-report delete drops the row early (medium confidence):
That branch already uses the new afterTransition pattern, so the bug is in TransitionTracker itself. Navigation.goBack schedules the callback via runAfterTransitions({waitForUpcomingTransition: true}) (Navigation.ts:511-538). waitForUpcomingTransition races React Navigation's transitionStart against a 1 s safety timer (MAX_TRANSITION_START_WAIT_MS); if no transitionStart event arrives, the callback fires immediately at the 1 s mark (TransitionTracker.ts:116-146). On the Search → MoneyRequestReportView pop in the reported scenario, the popping screen does not appear to emit transitionStart, so the fallback timer fires deleteAppReport while the close animation is still running.

Full code paths and evidence

• Delete trigger from More menu in transaction thread: useExpenseActions.ts:483-540
• Navigation back fires synchronously: navigateOnDeleteExpense → Navigation.goBack(backToRoute) with no options (ReportUtils.ts:6247-6261)
• Onyx optimistic mutation that hides the row: deleteTransactions → deleteMoneyRequest sets pendingAction: DELETE (DeleteMoneyRequest.ts:693-704)
• More-menu wiring (same for Spend and Inbox): MoneyReportHeaderSecondaryActions.tsx:293
• TransitionTracker event sources (React Navigation transitionStart/End): PlatformStackNavigation/ScreenLayout.tsx:24-34
• startTransition/endTransition + 1 s safety timer: TransitionTracker.ts:67-104
• Synchronous fast-path when no transition is active: TransitionTracker.ts:148-151

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

1. In the single-transaction delete branch of useExpenseActions, replace the synchronous navigateOnDeleteExpense(goBackRoute) + InteractionManager.runAfterInteractions(() => deleteTransactions(...)) pair with a single Navigation.goBack(goBackRoute, {afterTransition: () => deleteTransactions(...)}), mirroring the whole-report branch a few lines below.
2. Remove the now-unused InteractionManager import (the file's eslint-disable comment can come off too).
3. Investigate why the Search → MoneyRequestReportView pop does not produce a transitionStart event. Likely candidates: the popping screen unmounts before the listeners in ScreenLayout fire, or it is rendered outside the PlatformStackNavigation wrapper that attaches the listeners. Once identified, ensure the listeners are attached on the right screen so the 1 s fallback is not relied on for the happy path. As a defensive fallback, the MAX_TRANSITION_START_WAIT_MS value could be reduced or the strategy could be replaced with a deferred requestAnimationFrame chain when no transition is in flight — but the real fix is making the screen emit transition events.

What alternative solutions did you explore?

• Revert PR [BATCH 2] Migrate Navigation usage, part 1 #88538 — guaranteed to unblock the deploy, but loses the migration's wins and reintroduces the original regressions it set out to fix. Recommended only if the per-screen fix in (3) cannot be landed in time.
• Wrap the deletion in setTimeout(..., 350) to match the navigation animation duration — works but is brittle and is exactly the kind of pattern PR [BATCH 2] Migrate Navigation usage, part 1 #88538 was created to remove.

---

Related issues

• The PR's own test plan (Test 2 and Test 3 on #88538) describes the exact two scenarios that Applause is now flagging — suggesting these passed in the author's environment but regressed in QA, consistent with a transitionStart event mismatch by platform/layout.

---

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

[collectioneur]

After investigating, I discovered that the goBack animation for RHPs (both wide and Super Wide) is now much faster. I tested these two flows using my reverted PR and an AdHoc build. The transaction/report does get deleted after the animation ends, exactly as intended. However, due to the increased speed of the transition, it creates a visual illusion that the deletion happens before the transition finishes. I've attached two videos demonstrating that the transaction correctly waits for the transition to end:

2.mov

Also, when the transition starts, an unrelated bug occurs (the overlay's opacity doesn't animate with the transition). This also contributes to the illusion that the transaction deletes before transitionEnd. As shown in the video, this is not the case, the transaction properly deletes after the transition:

1.mov