[$250] Sign in - Account settings long loading if navigate via public room link & login as new account

[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.0.30-9
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): ponikarchuks+106924@gmail.com
Issue reported by: Applause - Internal Team

Issue found when executing PR #48144

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Log out
3. Go to this link https://staging.new.expensify.com/r/7075912447943023
4. Tap sign in
5. Enter credentials and log in as a new Gmail account

Expected Result:

Account settings loads fine

Actual Result:

Account settings long loading

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

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

Screenshots/Videos

Add any screenshot/video evidence

Bug6595301_1725625415082.A_clear_anonymous_user_records_after_login.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021836652520479378795
• Upwork Job ID: 1836652520479378795
• Last Price Increase: 2024-09-26

[melvin-bot]

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

[lanitochka17]

@bfitzexpensify 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

[bfitzexpensify]

Checking in on the other issue here

[bfitzexpensify]

I am heading out of office until September 21st, so assigning a buddy to watch over this in my absence.

Current status: confirming if the other PR caused this

[melvin-bot]

Current assignee @bfitzexpensify is eligible for the Bug assigner, not assigning anyone new.

[melvin-bot]

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

[jjcoffee]

This doesn't appear to be related to #47806 - I can repro with the changes from there reverted. It's probably a BE issue as there are no personalDetails returned in the SignUpUser call.

[melvin-bot]

@bfitzexpensify, @VictoriaExpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[VictoriaExpensify]

Thanks for confirming @jjcoffee . I'm going to move this to internal since this sounds like a BE issue

[VictoriaExpensify]

Not overdue

[trjExpensify]

Is this bug specific to the public rooms flow and on Android native only? If so, that was a project in #vip-vsb, and I think @jasperhuangg might be good to offer insight into that.

[jasperhuangg]

@jjcoffee The SignUpUser command isn't in charge of returning personal details, ReconnectApp/OpenApp is.

cc @marcochavezf IIRC you implemented this flow, it seems like we're not calling ReconnectApp when the user is signed in from the public room, which I think could be preventing us from loading their personal details.

Under normal circumstances when we sign up a new user we do call it:

So I believe this issue lies in the front-end and can be worked on externally, I think we just need to figure out why we're not calling ReconnectApp for that particular flow.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@bfitzexpensify @VictoriaExpensify @thesahindia 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!

[VictoriaExpensify]

@marcochavezf - have you got any insights to add to @jasperhuangg comment here?

[VictoriaExpensify]

Not overdue

[bfitzexpensify]

I'm back from OOO and can take this back over - thanks for looking after it @VictoriaExpensify!

[wildan-m]

Proposal

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

Slow loading times when accessing through a public room link and logging in as a new account.

What is the root cause of that problem?

A deadlock occurs when executing OpenApp while OpenReport is triggered.

Clicking the Join button triggers the openReport first.

App/src/pages/home/report/ReportActionsView.tsx

Lines 293 to 299 in b1720c7

	useEffect(() => {
	const wasLoginChangedDetected = prevAuthTokenType === CONST.AUTH_TOKEN_TYPES.ANONYMOUS && !session?.authTokenType;
	if (wasLoginChangedDetected && didUserLogInDuringSession() && isUserCreatedPolicyRoom(report)) {
	openReportIfNecessary();
	}
	// eslint-disable-next-line react-compiler/react-compiler, react-hooks/exhaustive-deps
	}, [session, report]);

Then openApp

App/src/pages/signin/SignInModal.tsx

Lines 30 to 34 in b1720c7

	if (!isAnonymousUser) {
	// Signing in RHP is only for anonymous users
	Navigation.isNavigationReady().then(() => Navigation.dismissModal());
	App.openApp();
	}

During openReport processing, communication gaps between client and server may cause the queue to pause.

App/src/libs/Network/SequentialQueue.ts

Lines 90 to 93 in b1720c7

	if (response?.shouldPauseQueue) {
	Log.info("[SequentialQueue] Handled 'shouldPauseQueue' in response. Pausing the queue.");
	pause();
	}

When that occurs, we are unable to process or clear the queue.

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

I think openApp should be the first request to call before everything else, since that API is responsible to make isLoadingApp to false.

Clear any persisted request in signInModal before calling openApp.

src/pages/signin/SignInModal.tsx

import * as PersistedRequests from '@libs/actions/PersistedRequests';

    useEffect(() => {
        const isAnonymousUser = session?.authTokenType === CONST.AUTH_TOKEN_TYPES.ANONYMOUS;
        if (!isAnonymousUser) {
            // Signing in RHP is only for anonymous users
            Navigation.isNavigationReady().then(() => Navigation.dismissModal());
            PersistedRequests.clear();
            App.openApp();
        }
    }, [session?.authTokenType]);

What alternative solutions did you explore? (Optional)

If we don't want to clear any pending requests, we can wait for the openApp function until the queue is idle.

src/pages/signin/SignInModal.tsx

import { waitForIdle } from '@libs/Network/SequentialQueue';

    useEffect(() => {
        const isAnonymousUser = session?.authTokenType === CONST.AUTH_TOKEN_TYPES.ANONYMOUS;
        if (!isAnonymousUser) {
            // Signing in RHP is only for anonymous users
            Navigation.isNavigationReady().then(() => Navigation.dismissModal());
            waitForIdle().then(() => {
                App.openApp();
            })
        }
    }, [session?.authTokenType]);

[melvin-bot]

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

[thesahindia]

@wildan-m's proposal looks good to me!

🎀 👀 🎀 C+ reviewed

[melvin-bot]

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

[lakchote]

@wildan-m could you please post a video doing the same reproduction steps with your fix?

It seems like your solution is different from what was imagined by @jasperhuangg with ReconnectApp.

[wildan-m]

If openApp gets stuck, the following queue, including reconnectApp, will also get stuck.

[lakchote]

If openApp gets stuck, the following queue, including reconnectApp, will also get stuck.

I'd still like to see the same reproduction steps with your fix, to see it in action.

cc @aldo-expensify was there a particular reason you wanted to trigger OpenReport first? To make sure we're not introducing unwanted side effects if we change the order of the API calls.

App/src/pages/home/report/ReportActionsView.tsx

Lines 293 to 299 in b1720c7

	useEffect(() => {
	const wasLoginChangedDetected = prevAuthTokenType === CONST.AUTH_TOKEN_TYPES.ANONYMOUS && !session?.authTokenType;
	if (wasLoginChangedDetected && didUserLogInDuringSession() && isUserCreatedPolicyRoom(report)) {
	openReportIfNecessary();
	}
	// eslint-disable-next-line react-compiler/react-compiler, react-hooks/exhaustive-deps
	}, [session, report]);

[wildan-m]

@lakchote My main solution used to work well, but now it's not functioning properly. The new user is not automatically joining, possibly due to recent changes.

My alternative solution still working properly, force redirection to concierge seems expected for a new user(?)

Kapture.2024-09-30.at.16.20.15.mp4

[lakchote]

@wildan-m thanks for checking it again.

My alternative solution still working properly, force redirection to concierge seems expected for a new user(?)

That seems valid to me too as it'll introduce the user to the platform. What do you think @trjExpensify?

[trjExpensify]

That seems valid to me too as it'll introduce the user to the platform. What do you think @trjExpensify?

Hm, I'm not sure. I don't think I agree with that. If you signed up from a public room, you would expect to drop back into the public room to continue what you were doing (like now being able to comment).