[Due for payment 2026-05-26] [Due for payment 2026-05-22] [Due for payment 2026-05-20] [$250] iOS - Login - Onboarding does not appear after creating a new account

[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.3.73-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: #89927
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 Pro Max / iOS 26.4.2
App Component: Other

Action Performed:

1. Launch Expensify app.
2. Log in.
3. Log out.
4. Log in with a new Gmail account.

Expected Result:

Onboarding will show up.

Actual Result:

Onboarding does not show up.
It only shows up after tapping New workspace on workspaces tab or relaunching the app.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7152558_1778657448171.ScreenRecording_05-13-2026_15-29-19_1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054480985877823861
• Upwork Job ID: 2054480985877823861
• Last Price Increase: 2026-05-13

Issue Owner

Current Issue Owner: @eh2077

[melvin-bot]

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

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

PR #89927 replaced InteractionManager.runAfterInteractions with TransitionTracker.runAfterTransitions in useOnboardingFlow.ts. These two APIs have a critical behavioral difference:

• InteractionManager.runAfterInteractions: Always schedules callbacks asynchronously (at minimum next microtask), even when no interactions are pending. This means the callback can be reliably cancelled by the useEffect cleanup before it executes, and only fires once values have stabilized.
• TransitionTracker.runAfterTransitions: Fires callbacks synchronously when no transitions are active (TransitionTracker.ts:143-145). The callback executes during every useEffect run and returns a no-op cancel handle.

Additionally, ScreenLayout does not call endTransition when a screen unmounts — it only removes the event listeners. If transitionStart fired before unmount, the transition handle becomes orphaned in activeTransitions until the 1000ms safety timeout. During this window, runAfterTransitions queues callbacks that get repeatedly cancelled and re-queued as the useEffect re-runs due to Onyx value changes.

On iOS during the logout→login flow, this timing mismatch means the onboarding callback either (a) fires synchronously during early effect runs when guard conditions (isLoadingApp, isOnboardingCompleted) haven't settled, or (b) gets queued behind an orphaned transition and flushed with stale closure values. Either way, startOnboardingFlow is never called.

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

Revert the InteractionManager → TransitionTracker change in useOnboardingFlow.ts, restoring the original InteractionManager.runAfterInteractions call. The onboarding hook depends on the async scheduling behavior to work correctly with the cancel-and-requeue pattern in its useEffect.

Additionally, fix ScreenLayout.tsx cleanup to end any active transition on unmount:

return () => {
    transitionStartListener();
    transitionEndListener();
    if (transitionHandleRef.current) {
        TransitionTracker.endTransition(transitionHandleRef.current);
        transitionHandleRef.current = null;
    }
};

What alternative solutions did you explore? (Optional)

• Making TransitionTracker.runAfterTransitions always asynchronous (wrapping the immediate callback in queueMicrotask) to match InteractionManager's behavior. This would fix this hook but could change behavior for other callers.
• Only reverting the useOnboardingFlow.ts change while keeping the BaseOnboardingInterestedFeatures.tsx change (which uses waitForUpcomingTransition: true and may not have the same issue).

Investigation details

Evidence chain:

1. The only code change in Migrate InteractionManager - batch 4 #89927 was replacing InteractionManager with TransitionTracker in two files
2. TransitionTracker.runAfterTransitions fires synchronously when activeTransitions.size === 0 (line 143), unlike InteractionManager which always defers
3. ScreenLayout registers transitionStart → startTransition() but cleanup only removes listeners without calling endTransition() — orphaning the transition handle
4. The useOnboardingFlow useEffect has ~20 dependencies that change during login, causing rapid re-runs where callbacks are cancelled and re-created
5. The symptom ("shows after tapping New workspace or relaunching") matches: a user action triggers a new effect run that resolves correctly, and a relaunch gives a clean slate

Possibly related issue: #84436 (onboarding modal not showing for invited members who haven't completed onboarding)

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.