[$250] mWeb/Safari - Public room-Onboarding flow not appear when sign in from reply thread of public room

[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: v9.3.24-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-5886/folder/13176964/41237765/1202916369
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 16 pro/ Safari
App Component: Other

Action Performed:

1. Navigate to this link - https://staging.new.expensify.com/r/1540486774487195 as anon user
2. Navigate to a thread
3. Hold a message for opening action menu and tap on Reply in thread
4. Type new email and complete login new account
5. Wait a time and tap back button to Inbox page

Expected Result:

The onboarding flow should appear after sign in

Actual Result:

The onboarding flow isn't appeared after sign in. Tap back button to Inbox, page loads infinitely
In some cases, the page freezes and onboarding modals open several times.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7083694_1771610219472.Yftl2604_1_.mp4

0-02-01-ce96144ba85ff942fffe7e03dbb0d7a8b9cd2347cf228d4f772b34f379d8af12_e69336f7d00d6d15.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022024911045743942557
• Upwork Job ID: 2024911045743942557
• Last Price Increase: 2026-03-16

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[abbasifaizan70]

Proposal

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

The onboarding flow does not appear after sign in. Tapping the back button to Inbox causes the page to load infinitely.

---

What is the root cause of that problem?

Onboarding and navigation guards both treat a missing ONYXKEYS.IS_LOADING_APP value as “app still loading.” After sign-in from “Reply in thread” on iOS Web Safari, the OpenApp flow may not set IS_LOADING_APP to false (e.g. due to timing or queue behavior on that platform), so the key can remain unset.

The hook defaults missing IS_LOADING_APP to true and returns early when isLoadingApp !== false, so the onboarding redirect never runs:

App/src/hooks/useOnboardingFlow.ts

Line 26 in d253f2b

const [isLoadingApp = true] = useOnyx(ONYXKEYS.IS_LOADING_APP, {canBeMissing: true});

App/src/hooks/useOnboardingFlow.ts

Lines 56 to 57 in d253f2b

	}

The guard context also treats missing as loading (value ?? true), so the OnboardingGuard skips redirecting to onboarding when context.isLoading is true:

App/src/libs/Navigation/guards/index.ts

Lines 26 to 29 in d253f2b

	key: ONYXKEYS.IS_LOADING_APP,
	callback: (value) => {
	isLoadingApp = value ?? true;
	},

Because the app never leaves the “loading” state, the user never sees onboarding. When they tap back to Inbox, other logic that assumes the app has finished loading can keep the UI in a loading state indefinitely.

---

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

Treat a missing ONYXKEYS.IS_LOADING_APP value as “not loading” (i.e. app ready) in both the onboarding hook and the navigation guards, so onboarding can run and the app is not stuck in a loading state after sign-in from “Reply in thread” on iOS Web Safari.

File: App/src/hooks/useOnboardingFlow.ts

-    const [isLoadingApp = true] = useOnyx(ONYXKEYS.IS_LOADING_APP, {canBeMissing: true});
+    const [isLoadingApp = false] = useOnyx(ONYXKEYS.IS_LOADING_APP, {canBeMissing: true});

File: App/src/libs/Navigation/guards/index.ts

 Onyx.connectWithoutView({
     key: ONYXKEYS.IS_LOADING_APP,
     callback: (value) => {
-        isLoadingApp = value ?? true;
+        isLoadingApp = value ?? false;
     },
 });

[MelvinBot]

Proposal

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

When an anonymous user visits a public room, navigates to a thread, taps "Reply in thread" (which triggers sign-in), and completes sign-in with a new account, the onboarding flow does not appear. Additionally, navigating back to the Inbox results in infinite loading (skeleton view never resolves).

What is the root cause of that problem?

The root cause is that the anonymous-to-authenticated transition bypasses the normal sign-in lifecycle, creating a race condition between navigation and data loading that prevents the onboarding flow from triggering.

Here's what happens step by step:

1. Anonymous users already have an authToken (of type ANONYMOUS), so useIsAuthenticated returns true and AuthScreens is mounted from the start (useIsAuthenticated.tsx:7).

2. When the user taps "Reply in thread," interceptAnonymousUser calls signOutAndRedirectToSignIn(). For anonymous users, this function returns early — it only opens the SIGN_IN_MODAL in the RHP without signing out or clearing Onyx (Session/index.ts:325-337).

3. After sign-in completes in the modal, SignInModal.tsx detects authTokenType !== ANONYMOUS and does two things: (a) calls Navigation.dismissModal() immediately, and (b) calls openApp(true) after waiting for queue idle (SignInModal.tsx:34-48).

4. The Navigation.dismissModal() triggers a navigation action that is evaluated by the OnboardingGuard. At this point, IS_LOADING_APP is still true (its default value in guards/index.ts:16 — let isLoadingApp = true), because openApp(true) hasn't been called yet (it's waiting for queue idle). The guard sees context.isLoading = true and returns ALLOW, skipping the onboarding redirect (OnboardingGuard.ts:151).

5. Since AuthScreens was already mounted during the anonymous session and never remounts (authenticated stays true), the mount-only useEffect that calls openApp() does not re-run (AuthScreens.tsx:255-283). The openApp(true) from SignInModal eventually fires, but by then the user has already navigated away from the modal.

6. When the user navigates back to the Inbox, SidebarLinksData reads IS_LOADING_APP (defaults to true) and since the new user's report data hasn't fully loaded, SidebarLinks renders the skeleton loading view indefinitely (SidebarLinks.tsx:94-98).

Additionally, the hasCompletedGuidedSetupFlowSelector returns true for empty/undefined NVP_ONBOARDING objects (Onboarding.ts:12-19), so if the guard evaluates before the new user's NVP data loads, isOnboardingCompleted is also incorrectly true.

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

The fix should ensure that after a successful anonymous-to-authenticated sign-in via the SIGN_IN_MODAL, the app properly triggers onboarding and loads data for the new user. Specifically:

In SignInModal.tsx, the openApp(true) call should complete before Navigation.dismissModal() is called (or at least ensure IS_LOADING_APP is properly managed before the dismiss navigation action triggers the guard). The flow should be:

1. Wait for openApp(true) to complete (so IS_LOADING_APP transitions true → false and NVP_ONBOARDING is loaded)
2. Then dismiss the modal — at this point the OnboardingGuard will have accurate data and can properly redirect to onboarding if hasCompletedGuidedSetupFlow === false

Alternatively, after the anonymous-to-authenticated transition completes and IS_LOADING_APP becomes false, explicitly trigger a navigation action (e.g., Navigation.resetToHome()) so the OnboardingGuard gets a chance to re-evaluate with the correct onboarding state and redirect appropriately.

What alternative solutions did you explore? (Optional)

1. Full navigation reset on anonymous-to-auth transition: Call Onyx.clear() and do a complete session reset (like the normal sign-out/sign-in flow). This would fix the issue but is more disruptive and could lose the context of which public room the user was viewing.

2. Add an explicit onboarding check after sign-in in SignInModal: After openApp completes, check NVP_ONBOARDING.hasCompletedGuidedSetupFlow and explicitly navigate to onboarding if needed, bypassing the guard. This works but duplicates the guard logic.

3. Make OnboardingGuard re-evaluate on Onyx data changes: Instead of only evaluating on navigation actions, have the guard trigger a navigation reset when IS_LOADING_APP transitions from true to false and onboarding is incomplete. This is more architecturally complex but would fix similar edge cases.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[shubham1206agra]

@TMisiukiewicz This looks related to #81689. Can you please check this?

[imgyf]

Proposal

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

When an anonymous user signs in via the SignInModal (triggered by "Reply in thread" in a public room), the onboarding flow does not appear. Navigating back to the Inbox shows infinite loading.

What is the root cause of that problem?

In src/pages/signin/SignInModal.tsx (lines 38-49), when authTokenType changes from ANONYMOUS to a real token, two things happen in parallel:

1. Navigation.dismissModal() fires immediately
2. waitForIdle().then(() => openApp(true)) fires asynchronously (after the sequential queue is idle)

The dismiss triggers the OnboardingGuard (src/libs/Navigation/guards/OnboardingGuard.ts:151), which checks context.isLoading. At this point IS_LOADING_APP is still true (its default in src/libs/Navigation/guards/index.ts:16) because openApp(true) hasn't been called yet. The guard sees shouldSkipOnboarding = true due to context.isLoading and returns ALLOW, skipping the onboarding redirect entirely.

Additionally, hasCompletedGuidedSetupFlowSelector in src/selectors/Onboarding.ts:13-17 returns true for empty NVP_ONBOARDING objects. Before openApp loads the new user's NVP data, the onboarding value is likely empty/default, so even if isLoading were resolved, onboarding could still be incorrectly marked as completed.

The infinite loading on Inbox occurs because IS_LOADING_APP remains in an ambiguous state — AuthScreens was already mounted during the anonymous session and its mount-only useEffect that calls openApp() does not re-run (src/libs/Navigation/AppNavigator/AuthScreens.tsx:255-283).

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

In src/pages/signin/SignInModal.tsx, reverse the ordering so that openApp(true) completes before dismissing the modal. This ensures that when dismissModal() triggers the OnboardingGuard, IS_LOADING_APP has transitioned to false and NVP_ONBOARDING is loaded with the new user's actual onboarding state.

Change the useEffect so that instead of firing dismissModal and openApp independently:

• First await waitForIdle()
• Then await openApp(true) (which resolves after IS_LOADING_APP is set to false)
• Then call Navigation.dismissModal()

This way the guard evaluates with accurate data: isLoading is false, and isOnboardingCompleted reflects the new user's actual NVP state (hasCompletedGuidedSetupFlow === false for a brand-new account), so the guard correctly redirects to the onboarding flow.

What alternative solutions did you explore? (Optional)

1. Adding an explicit Navigation.resetToHome() after openApp completes — this would force the guard to re-evaluate, but is less clean since it introduces a redundant navigation action.
2. Making OnboardingGuard subscribe to IS_LOADING_APP changes and re-evaluate — architecturally complex and would affect all guard evaluations.