Web/mWeb- Sign in - Endless loading spinner appears when re login

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Expected Result:

Able to log in to the account without any issue

Actual Result:

Infinite loading spinner appears on tapping "continue" after entering the email

Action Performed:

1. Go to https://staging.expensify.cash/
2. Log in with any account
3. Log out
4. Log in again with same account or different account

Workaround:

Unknown

Platform:

Web ✔️
iOS
Android
Desktop App
Mobile Web ✔️

Version Number:
1.0.66-0
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Bug5105359_Screen_Recording_20210609-144211_Chrome.mp4

Expensify/Expensify Issue URL:

View all open jobs on Upwork

[MelvinBot]

Triggered auto assignment to @Christinadobrzyn (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

[OSBotify]

👋 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]

Triggered auto assignment to @Luke9389 (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[Christinadobrzyn]

Trying to replicate this on my mobile app - Staging e.cash v1.0.55-1

I'm not getting the same loading page when I sign in to a different account, I assume that is because I'm not logging into the second account as quickly as in the video @kavimuru so kindly created.

I don't see any other GH's about this issue so I think it's up to engineering if this is something to fix now or wait.

[Christinadobrzyn]

I'm also not sure if the deploy blocker label is needed on this GH - @Luke9389 - can you confirm? I'm changing this issue to daily.

[trjExpensify]

👋 @Christinadobrzyn, did you try to reproduce on Web and mWeb and on version v1.0.66-0 or higher?

All deploy blockers are set to hourly for urgency. Let's keep it on that until we prove this isn't an issue or not. Essentially, if this gets deployed to production and users can't sign-in to E.cash, that's pretty bad.

FWIW, I can see the issue on Web on the latest v1.0.66-5, and now I'm unable to sign-in 😅

[Christinadobrzyn]

Ah thanks for jumping in @trjExpensify I don't have a version higher than v1.0.55-1. Asking permission for v1.0.66-0 in Slack.

I tried on the mobile app, not on the web. Does this fix need an external contractor or are we fixing this internally?

[trjExpensify]

Yeah, you'll need the alpha for the latest staging version on the mobile app. For testing Web/mWeb issues like this one, if you go to staging.expensify.cash, those will always be the latest for yah.

Does this fix need an external contractor or are we fixing this internally?

hourly deploy blockers are typically kept internal 👍

[trjExpensify]

@Luke9389 is largely OoO today, so we're repulling the deploy blocker assignment trigger given that it's an hourly deploy blocker that's blocking N5.

[MelvinBot]

Triggered auto assignment to @pecanoro (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[trjExpensify]

Bingo! :)

[pecanoro]

Sorry guys, but I definitely can't take care either, cash bonus payroll project is extremely urgent and have a super tight deadline 😢

[pecanoro]

Can we use the demolition label here? It has really clear reproduction steps

[MelvinBot]

@trjExpensify the Demolition label can only be added by an Engineer or a member of the Engineering Demolition Team.

[MelvinBot]

Triggered auto assignment to @alex-mechler (Demolition), see https://stackoverflow.com/c/expensify/questions/8099 for more details.

[trjExpensify]

Yep, cool. As long as someone takes it, as it is preventing us from being able to ship N5. 👍

[alex-mechler]

I can take care of this today!

[alex-mechler]

Okay, found the root cause. When we go to sign out, we clean up the logins we create, and delete it here. However, since we have sped up onyx, we now delete our auth token before we fire this request, causing it to fail, and lock the network since we don't have a auth token. We only unlock the network when we get a valid authtoken again.

Moving the delete login request before we clear the authtoken solves this problem, but I am running into a few other problems that still have to be solved with it

[roryabraham]

Oops, @kidroca made Onyx too fast 🙃

[kidroca]

I think we have the same problem we concluded here: #3485 (comment)

And maybe it would be best to make a PR to move the call to keysChanged to the next tick as suggested in the link above
This way you won't have to change the code here and on other places suffering from this speed up

cc @marcaaron

[alex-mechler]

Alright, so I have a fix PR. It has uncovered some other bugs, which I think are related to the cache that was recently added.

1. When signing into an account after the signout, the loading spinner is not cleared on the password page. account.loading is set to false in local storage at this time.
2. After signing into the account after the signout, You are brought to /r/, with no report ID.

Both of these issues are solved when using the commit before caching was introduced to Onyx, 0cdf133867dccbd0b99090850130fef3442e826f, which leads me to believe the caching is causing these issues.

I think we have the same problem we concluded here: #3485 (comment)

And maybe it would be best to make a PR to move the call to keysChanged to the next tick as suggested in the link above
This way you won't have to change the code here and on other places suffering from this speed up

I tested this locally, and while it did work, it introduced another issue where the Magic Sign link page would briefly appear on the screen before switching over to the Password Form.

[Julesssss]

And maybe it would be best to make a PR to move the call to keysChanged to the next tick as suggested in the link above
This way you won't have to change the code here and on other places suffering from this speed up

@kidroca maybe this is the best path forward, would you be able to raise a PR with this change so we can discuss it further? Do you think that would resolve the issues raised by Alex above?

[Julesssss]

I tested this locally, and while it did work, it introduced another issue where the Magic Sign link page would briefly appear on the screen before switching over to the Password Form.

Hey @alex-mechler. It looks like this might be the best path forward to unblocking the N5 release. Would you mind pushing this change so we can investigate a fix to the hopefully final issue of the Magic sign in appearing? Thanks 🙇‍♂️

[alex-mechler]

Sure, I can take care of that

[alex-mechler]

So with that fix in Onyx, issue 2 (After signing into the account after the signout, You are brought to /r/, with no report ID) still exists after signing out and then back into a new account. currentlyViewedReportID is NaN in Local Storage.

I've pushed what I have to amechler-fix-signout in expensify.cash if anyone else wants to jump on looking for why this happens as well.

[Julesssss]

PR looks good to me. As discussed, I think the remaining redirect to /r issue is probably not worth blocking the release over.

[alex-mechler]

PR is up, follow up issue for the /r/ bug here