[Due for payment 2026-03-30] Android - Scan - App returns to confirm page after tapping Replace

[lanitochka17]

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.40-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: #83899
Email or phone of affected tester (no customers): sdjsdjosijnsodiosd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Money Requests

Action Performed:

1. Launch Expensify app.
2. Go to workspace chat.
3. Tap + > Create expense > Scan.
4. Upload a photo.
5. On confirm page, tap on the receipt.
6. Tap Replace.

Expected Result:

Replace receipt page will open.

Actual Result:

App returns to confirm page after tapping Replace.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7106302_1773843536694.13.mp4

View all open jobs on GitHub

[melvin-bot]

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

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #83899 - "Migration navigation from InteractionManager to TransitionTracker V2" by @collectioneur (High confidence)
Related Issues: #85687 (same root cause), part of #71913 (TransitionTracker migration parent issue)

Recommendation: REVERT

PR #83899 introduces the TransitionTracker system to replace InteractionManager for handling navigation transitions. The bug occurs when tapping "Replace" on a receipt in the confirmation page - instead of navigating to the replace receipt page, the app returns to the confirm page.

This is one of several Android-specific navigation failures introduced by this PR, all sharing the same root cause.

Labels: No changes needed. DeployBlockerCash is correctly applied (blocks App deploy). Issue is not reproducible on production, only staging, confirming it was introduced in this deploy.

📋 Detailed Analysis

Evidence

• The issue is only reproducible on staging, not production, confirming it was introduced in the current deploy
• PR Migration navigation from InteractionManager to TransitionTracker V2 #83899 was explicitly mentioned in the issue by melvin-bot as the suspected cause
• The bug affects Android-specific navigation behavior
• The symptom (receipt replace page not opening) directly relates to the modal dismissal and navigation changes in the PR
• Multiple other Android navigation bugs ([Due for payment 2026-03-30] Android - Chat does not open after closing chat and opening another chat from FAB #85687) share the same root cause

Verification

The PR modified src/pages/media/AttachmentModalScreen/routes/TransactionReceiptModalContent.tsx at lines 521-527.

Before (working on production):

if (isNative) {
    Navigation.goBack();
    Navigation.setNavigationActionToMicrotaskQueue(() => {
        Navigation.navigate(getDestinationRoute());
    });
    return;
}

Navigation.dismissModal({
    callback: () => Navigation.navigate(getDestinationRoute()),
});

After (broken on staging):

Navigation.dismissModal({
    afterTransition: () => Navigation.navigate(getDestinationRoute()),
});

The PR removed the Android-specific navigation flow that used goBack() + setNavigationActionToMicrotaskQueue() and replaced it with the unified dismissModal({ afterTransition }) approach powered by TransitionTracker.

Root Cause

The TransitionTracker system relies on transitionStart and transitionEnd events from React Navigation to track when transitions complete. The dismissModal function with afterTransition calls:

TransitionTracker.runAfterTransitions({
    callback: afterTransition,
    waitForUpcomingTransition: true
});

The waitForUpcomingTransition: true flag creates an async flow that waits for the next startTransition() call before queuing the callback.

On Android with @react-navigation/native-stack, the Fragment-based screen management can cause the ScreenLayout component to be torn down before the transitionEnd event fires for the disappearing screen. This leaves startTransition() called (incrementing activeCount) but the corresponding endTransition() never fires, leaving activeCount stuck at a positive value.

While there's a 1000ms safety timeout, the accumulated transition imbalance means the afterTransition callback (which navigates to the replace receipt page) gets queued but waits indefinitely for activeCount to reach 0. From the user's perspective, nothing happens when they tap "Replace" - they just return to the confirm page.

This is Android-specific because of how react-native-screens manages Fragment lifecycle differently than iOS UIKit.