[HOLD for payment 2024-10-29] [$250] Sign in-User remains in first step of Onboarding when tapping an option after closing the app

[IuliiaHerets]

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.0.42-3
Reproducible in staging?: Y
Reproducible in production?: Y
Issue reported by: Applause Internal Team

Action Performed:

1. Open the New Expensify app
2. Log in with new gmail account
3. Close the app and reopen
4. Tap on any option in onboarding modal

Expected Result:

The next step of onboarding flow should be displayed.

Actual Result:

User remains on the same page.

Workaround:

Unknown

Platforms:

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6622099_1727873782030.Record_2024-10-02-14-55-13.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021843801370397066465
• Upwork Job ID: 1843801370397066465
• Last Price Increase: 2024-10-15
• Automatic offers:
• dukenv0307 | Reviewer | 104442039
• truph01 | Contributor | 104442040

Issue Owner

Current Issue Owner: @stephanieelliott

[melvin-bot]

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

[IuliiaHerets]

We think that this bug might be related to #wave-collect - Release 1

[IuliiaHerets]

@stephanieelliott FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[bernhardoj]

Proposal

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

The onboarding modal shows again from the first step after selecting an option if we reopen the app.

What is the root cause of that problem?

When we open the app, the onboarding page is shown by useOnboardingFlowRouter hook and the linking listener here is triggered with an empty URL string.

App/src/Expensify.tsx

Lines 207 to 210 in bad93d5

	// Open chat report from a deep link (only mobile native)
	Linking.addEventListener('url', (state) => {
	Report.openReportFromDeepLink(state.url);
	});

Inside the function, we check whether the user already completed the onboarding or not. It's to prevent the user from deep-linking to another page if the onboarding hasn't been completed yet.

App/src/libs/actions/Report.ts

Lines 2683 to 2721 in bad93d5

	Navigation.waitForProtectedRoutes().then(() => {
	if (route && Session.isAnonymousUser() && !Session.canAnonymousUserAccessRoute(route)) {
	Session.signOutAndRedirectToSignIn(true);
	return;
	}
	// We don't want to navigate to the exitTo route when creating a new workspace from a deep link,
	// because we already handle creating the optimistic policy and navigating to it in App.setUpPoliciesAndNavigate,
	// which is already called when AuthScreens mounts.
	if (url && new URL(url).searchParams.get('exitTo') === ROUTES.WORKSPACE_NEW) {
	return;
	}
	const handleDeeplinkNavigation = () => {
	const state = navigationRef.getRootState();
	const currentFocusedRoute = findFocusedRoute(state);
	if (isOnboardingFlowName(currentFocusedRoute?.name)) {
	Welcome.setOnboardingErrorMessage(Localize.translateLocal('onboarding.purpose.errorBackButton'));
	return;
	}
	if (shouldSkipDeepLinkNavigation(route)) {
	return;
	}
	if (isAuthenticated) {
	return;
	}
	Navigation.navigate(route as Route, CONST.NAVIGATION.ACTION_TYPE.PUSH);
	};
	// We need skip deeplinking if the user hasn't completed the guided setup flow.
	Welcome.isOnboardingFlowCompleted({
	onNotCompleted: OnboardingFlow.startOnboardingFlow,
	onCompleted: handleDeeplinkNavigation,
	onCanceled: handleDeeplinkNavigation,
	});

But, we only execute it if the protected routes are ready. So, the checking is currently pending. The function will wait for the navigation to be ready first, however, even after the nav is ready, the state is undefined.

App/src/libs/Navigation/Navigation.ts

Lines 391 to 404 in bad93d5

	isNavigationReady().then(() => {
	const currentState = navigationRef.current?.getState();
	if (navContainsProtectedRoutes(currentState)) {
	resolve();
	return;
	}
	const unsubscribe = navigationRef.current?.addListener('state', ({data}) => {
	const state = data?.state;
	if (navContainsProtectedRoutes(state)) {
	unsubscribe?.();
	resolve();
	}
	});

The ready promise is resolved here, which doesn't guarantee that the state is ready.

App/src/libs/Navigation/NavigationRoot.tsx

Line 181 in bad93d5

onReady={onReady}

We also resolve the promise here whenever the state is changed.

App/src/libs/Navigation/NavigationRoot.tsx

Line 76 in bad93d5

Navigation.setIsNavigationReady();

We can remove the first resolve from onReady, but the nav state still doesn't contains routeNames property yet which is required when checking the protected route.

App/src/libs/Navigation/Navigation.ts

Lines 369 to 375 in bad93d5

	function navContainsProtectedRoutes(state: State | undefined): boolean {
	if (!state?.routeNames || !Array.isArray(state.routeNames)) {
	return false;
	}
	// If one protected screen is in the routeNames then other screens are there as well.
	return state?.routeNames.includes(PROTECTED_SCREENS.CONCIERGE);

Only after we complete the first step by selecting any option, the protected route becomes available, and the pending onboarding flow check is executed, which triggers the 2nd startOnboardingFlow.

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

We actually have a logic to ignore the onboarding start if the onboarding is currently in progress,

App/src/libs/actions/Welcome/index.ts

Lines 41 to 56 in 837152e

	let isOnboardingInProgress = false;
	function isOnboardingFlowCompleted({onCompleted, onNotCompleted, onCanceled}: HasCompletedOnboardingFlowProps) {
	isOnboardingFlowStatusKnownPromise.then(() => {
	if (Array.isArray(onboarding) || onboarding?.hasCompletedGuidedSetupFlow === undefined) {
	onCanceled?.();
	return;
	}
	if (onboarding?.hasCompletedGuidedSetupFlow) {
	isOnboardingInProgress = false;
	onCompleted?.();
	} else if (!isOnboardingInProgress) {
	isOnboardingInProgress = true;
	onNotCompleted?.();
	}
	});

however, it uses a local variable which is only updated within the Welcome file, but the initial onboarding is started from useOnboardingFlowRouter hook.

We can create a global variable to hold it, but I think a cleaner way to check if an onboarding is in progress is to check the focused route. If it's an onboarding modal navigator, then the onboarding is in progress.

function isOnboardingInProgress() {
    return navigationRef.current?.getRootState().routes?.at(-1)?.name === NAVIGATORS.ONBOARDING_MODAL_NAVIGATOR;
}

if (onboarding?.hasCompletedGuidedSetupFlow) {
    onCompleted?.();
} else if (!isOnboardingInProgress()) {
    onNotCompleted?.();
}

In openReportFromDeepLink, we can early return if url is empty, but that doesn't solve the root cause since we can open the app using deep link

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[stephanieelliott]

Is this still happening? I'm not able to repro this on either platform --

RPReplay_Final1727995452.MP4

@IuliiaHerets if it's still reproducible for you, can you please confirm the repro steps in the issue body?

[bernhardoj]

This is still happening to me

ios.mp4

[melvin-bot]

@stephanieelliott Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[stephanieelliott]

Ok, this is a critical flow and the issue makes sense given the proposal, so we should move forward with fixing it. Applying labels.

[melvin-bot]

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

[melvin-bot]

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

[dukenv0307]

@bernhardoj Thanks for your proposal, do you know why this issue doesn't happen on web?

[bernhardoj]

This happen on web too.

web.mp4

[melvin-bot]

@stephanieelliott, @dukenv0307 Huh... This is 4 days overdue. Who can take care of this?

[stephanieelliott]

Hey @dukenv0307 were you able to review the proposal here? Any thoughts on the solution that @bernhardoj is proposing?

[dukenv0307]

I'm reviewing...

[dukenv0307]

Checking the focused route is not a good idea. We can update isOnboardingInProgress in startOnboardingFlow, what do you think? @bernhardoj

[bernhardoj]

We can definitely do that, but isOnboardingInProgress is only updated to false when calling isOnboardingFlowCompleted for the second time after completing it.

App/src/libs/actions/Welcome/index.ts

Lines 41 to 54 in a333676

	let isOnboardingInProgress = false;
	function isOnboardingFlowCompleted({onCompleted, onNotCompleted, onCanceled}: HasCompletedOnboardingFlowProps) {
	isOnboardingFlowStatusKnownPromise.then(() => {
	if (Array.isArray(onboarding) || onboarding?.hasCompletedGuidedSetupFlow === undefined) {
	onCanceled?.();
	return;
	}
	if (onboarding?.hasCompletedGuidedSetupFlow) {
	isOnboardingInProgress = false;
	onCompleted?.();
	} else if (!isOnboardingInProgress) {
	isOnboardingInProgress = true;
	onNotCompleted?.();

If we perform:

1. Sign in as a new user
2. Deep-link to any page twice (e.g., settings), the onboarding flow won't show anymore.

What happened is, that when we deep link to A, page A is open, and Welcome.isOnboardingFlowCompleted is called, but because isOnboardingInProgress is still true, the onboarding flow won't show anymore.

App/src/libs/actions/Report.ts

Lines 2714 to 2718 in a333676

	Welcome.isOnboardingFlowCompleted({
	onNotCompleted: OnboardingFlow.startOnboardingFlow,
	onCompleted: handleDeeplinkNavigation,
	onCanceled: handleDeeplinkNavigation,
	});

It's actually a different issue with how we handle the deep link, but it shows that the isOnboardingProgress variable is currently not reliable.

Do you have any concerns with checking the focused route?

[truph01]

Proposal

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

User remains on the same page.

What is the root cause of that problem?

When users open App from Deeplink, the logic here is executed

App/src/Expensify.tsx

Lines 208 to 210 in ec3e940

	Linking.addEventListener('url', (state) => {
	Report.openReportFromDeepLink(state.url);
	});

That should execute the startOnboarding flow

App/src/libs/actions/Report.ts

Lines 2717 to 2721 in bad93d5

	Welcome.isOnboardingFlowCompleted({
	onNotCompleted: OnboardingFlow.startOnboardingFlow,
	onCompleted: handleDeeplinkNavigation,
	onCanceled: handleDeeplinkNavigation,
	});

But it’s not triggered since Navigation.waitForProtectedRoutes() is still pending.
waitForProtectedRoutes promise is resolved only when navContainsProtectedRoutes(currentState) is true

App/src/libs/Navigation/Navigation.ts

Line 393 in ec3e940

if (navContainsProtectedRoutes(currentState)) {

That means state?.routeNames includes CONCIERGE chat

App/src/libs/Navigation/Navigation.ts

Line 375 in ec3e940

return state?.routeNames.includes(PROTECTED_SCREENS.CONCIERGE);

Unfortunately, the state at that time doesn’t contain routeNames. Why?
Because we have the logic to resetRoot in

App/src/libs/actions/Welcome/OnboardingFlow.ts

Line 113 in 6ece6b0

navigationRef.resetRoot(adaptedState);

And we get adaptedState from getAdaptedStateFromPath, but the state here doesn’t contain the routeNames

https://github.com/react-navigation/react-navigation/blob/1ad42666923bd76dd9e7dd731ba39cc31dd27317/packages/core/src/getStateFromPath.tsx#L134

And createNestedStateObject just returns index and routes

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

We have the same place to resetState in

App/src/libs/actions/Welcome/OnboardingFlow.ts

Line 59 in 6ece6b0

const adaptedState = rootState;

And the adaptedState is rootState (that contains routeNames), so we should pass the rootState and adaptedState in startOnboardingFlow

    navigationRef.resetRoot({
        ...navigationRef.getRootState(),
        ...adaptedState,
        stale: true,
    } as PartialState<NavigationState>);

Or just add routeNames

What alternative solutions did you explore? (Optional)

1. We can use getRootState in

App/src/libs/Navigation/Navigation.ts

Line 392 in ec3e940

const currentState = navigationRef.current?.getState();

Because getRootState get the correct state within routeNames from keyedListeners instead of stateRef.current like getState

https://github.com/react-navigation/react-navigation/blob/1ad42666923bd76dd9e7dd731ba39cc31dd27317/packages/core/src/BaseNavigationContainer.tsx#L171-L173

2. Update getStateFromPath function to return routeNames

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[dukenv0307]

Thanks for your proposals.

@bernhardoj Using focused route is the workaround to me since we don't actually know why the state doesn't contain routeNames.

@truph01 explains the details and correct RCA. We can go with @truph01's main solution.

🎀👀🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @lakchote, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[lakchote]

I prefer @truph01's solution too, the solution correctly addresses the RCA.

@truph01's solution LGTM.

[melvin-bot]

📣 @dukenv0307 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[melvin-bot]

📣 @truph01 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[melvin-bot]

@lakchote @stephanieelliott @dukenv0307 @truph01 this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.51-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: User remains in first step of Onboarding #50979

If no regressions arise, payment will be issued on 2024-10-29. 🎊

For reference, here are some details about the assignees on this issue:

• @dukenv0307 requires payment automatic offer (Reviewer)
• @truph01 requires payment automatic offer (Contributor)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@dukenv0307] The PR that introduced the bug has been identified. Link to the PR:
• [@dukenv0307] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@dukenv0307] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@dukenv0307] Determine if we should create a regression test for this bug.
• [@dukenv0307] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@stephanieelliott] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[dukenv0307]

BugZero Checklist:

• The PR that introduced the bug has been identified. Link to the PR: N/A
• The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: N/A
• A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A
• Determine if we should create a regression test for this bug. Yes
• If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Regression test:

1. Open the New Expensify app
2. Log in with new gmail account
3. Close the app and reopen
4. Tap on any option in onboarding modal
5. Verify the next step of onboarding flow should be displayed.

Do we 👍 or 👎