[$500] Login – No Abracadabra page when logging in via Magic link

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.3-1
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4678326
Email or phone of affected tester (no customers): [email protected]
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Log in with new Expensifail account
3. Copy the Magic link and change it to staging
4. Open a new tab and navigate to the staging magic link

Expected Result:

Abracadabra page is displayed

Actual Result:

Inbox page opens. Abracadabra page isn’t displayed

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

Bug6527186_1719565721053.no_Abracadabra_page.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01e239faee992134cd
• Upwork Job ID: 1806768165074984740
• Last Price Increase: 2024-08-13
• Automatic offers:
• HezekielT | Contributor | 103331186

Issue Owner

Current Issue Owner: @kirillzyusko

[melvin-bot]

Triggered auto assignment to @garrettmknight (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]

Triggered auto assignment to @dangrous (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

[izarutskaya]

@garrettmknight 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.

[dangrous]

This is definitely external. Haven't figured out the cause yet, I need to remember how to send magic links from dev.

[dangrous]

So I just tried this with the production build and the production server on my local and still had it occur.

I think this might be something just with copying and modifying the link, rather than literally clicking on it... I vaguely remember something about that in another bug in the past. But I'm not confident yet - other ideas welcome!

[dangrous]

Trying to get some assistance here - https://expensify.slack.com/archives/C01GTK53T8Q/p1719583721705269

[garrettmknight]

The abracadabra page is just a confirmation so I don't think we need to call this a blocker.

[melvin-bot]

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

[hannojg]

why email link can be received in 2 formats? Sometimes it is

To answer that part I think that happens through the email tool expensify uses to send the mails and its a question of whether your email client followed the redirect yet. You can put the url in curl to get the /v/ url, as it won't follow the redirect:

[dangrous]

@hannojg I saw an email about a comment you sent confirming expected behavior, since that's deleted I'm guessing you figured it out? Short version - yes, opening the magic link should authenticate the original tab/window.

[hannojg]

Yeah, sorry, when writing that comment I was still confused 😄

So, we've found a solution, however, that solution currently doesn't work in strict mode (debug), but will work in release. How open are we to "only" fix that for release and not debug?

We can spend more hours making this fix also viable for debug, just wanted to check with you first if its worth the effort?

[hannojg]

Note: we actually have a solution available now that works also in strict mode 😊

[dangrous]

oh awesome!

[hannojg]

We have a PR here which fixes the issue:

• fix: react-navigation disable buggy automatic cleanup mechanism #48347

Screen.Recording.2024-08-30.at.17.42.11.mov

The main fix we found is to disable the cleaning mechanism entirely when switching navigators in react-navigation. When we sign in and switch from our PublicScreens to AuthScreens we explicitly expect the navigation state to persist. There are no built-in mechanisms to stop the cleanup from happen (it has internal logic for that but it is buggy as Kiryl pointed out).
Instead we add an explicit clean point when we signout, as this is the only place to my understanding where we'd ever want to drop our navigation state.

Alternative solutions

The main problem is, that react-navigation's cleanup mechanism is build on the assumption that when you unmount a navigator, you either instantly mount a new one - or no new navigator is mounted instantly, in which case we want to clear the state.

In Expensify's case our navigators are wrapped with <Suspense /> and it can happen that our navigators "are rendered" but are only really mounted after X milliseconds. This breaks react-navigation's assumption.

We could work out a reproduction for react-navigation, open an issue there, and work on a fix with Satya, but I believe this could take days. Not sure if thats worth for that issue?

[hannojg]

I will finish the PR with testing all platforms tomorrow - however, we could already assign someone for testing (or do an adhoc build and ask people to test it). I am slightly unsure whether I overlooked some case where we'd also need to clean the navigator state.

[dangrous]

okay great! Yeah I think if it's only specifically this issue, we can fix it the way you said rather than going into react-navigation. Probably not worth that.

As for testing, @aimane-chnaif you up for starting to take a look at it?

[hannojg]

Note: I am OOO, back on Wednesday. I realised that in the PR I do a thing that shouldn't be needed, and there seems to be a bug in react-navigation with that. Will continue on Wednesday (or @kirillzyusko feel free to take over while I am away if you're available).

Note: probably not worth to review the PR now, lets wait until we have a fix react for react-navigation @aimane-chnaif

[dangrous]

How are we looking on this one @hannojg? Thanks!

[kirillzyusko]

@dangrous Hanno is OOO for two weeks, so I'm taking this over again and will try to fix it ASAP!

[melvin-bot]

This issue has not been updated in over 15 days. @garrettmknight, @dangrous, @kirillzyusko, @HezekielT, @aimane-chnaif eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[dangrous]

Waiting on library review

[dangrous]

we're discussing expected behavior for this one again, we may not end up needing it?

https://expensify.slack.com/archives/C03TQ48KC/p1730456781086199

[dangrous]

Okay we're closing this issue, and will update the expected behavior to match the current behavior. Thanks for investigating @kirillzyusko!!

Can anyone confirm whether or not we need payment here? It's been a long road with a lot of PRs (many of which reverted) so I'm a little confused haha

[dangrous]

i'm going to go ahead and close and if anyone needs payment we can reopen