Account - Unable to authenticate a 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.13-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Action Performed:

1. Sign in to new dot with a new Gmail account
2. Finish the onboarding flow
3. Once you are signed in navigate to Account Settings> Profile > Contact Method
4. Click on your contact method (has a GBR since the account is not verified yet)
5. Wait for the Magic Code to arrive in your Gmail
6. Click on "Didn't receive a magic code?"
7. A system message appears that a link has been resent
8. Wait for the Magic code to arrive
9. Repeat step 6 several times

Expected Result:

Magic sign-in code is received when trying to authenticate a new account

Actual Result:

Magic sign-in code is not received when trying to authenticate a new account

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

Bug6553385_1721979079518.2024-07-26_10_12_50.mp4

View all open jobs on GitHub

[melvin-bot]

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

[arosiclair]

Reproduced on staging v9.0.13-2. No magic code is received from the contact method page but the code still works from the sign in page.

[arosiclair]

On prod v9.0.12-0, opening the contact method page also does not send a magic code like it should. However, clicking Didn't receive a magic code? does work. So the resend button not working is new.

	Open ContactMethodDetailsPage	Didn't receive a magic code? link
Staging	❌	❌
Prod	❌	✅

[arosiclair]

Alright switching the the prod API fixes the Didn't receive a magic code? link so this is definitely not an App blocker.

[arosiclair]

I think this is probably due to https://github.com/Expensify/Web-Expensify/pull/42825 cc @dangrous

After creating a new account, we're calling RequestContactMethodValidateCode for the primary login, but this calls UserAPI::requestSecondaryLoginValidationLink with the new params we added which probably doesn't work.

[arosiclair]

Alright I was able to reproduce in dev and reverting https://github.com/Expensify/Web-Expensify/pull/42825 fixed the issue.

The root problem is that setting isSecondaryLogin and skipping this block causes a SetCashPassword email notification to get queued here. This doesn't work since that kind of email doesn't exist anymore (there's no template for it in Web-E) which makes sense since we don't support passwords anymore:

[alrt] [genintho] Notification_Utils - Unable to load template ~~ template: 'SetCashPassword' to: 'arosiclair+validate2@expensifail.com'

I think this approach was probably the wrong one anyway (should just check if the login is secondary in Auth rather than passing params), so I'm going to post a PR to have this reverted.

[dangrous]

oh i see, so even for a non-secondary account we're still sending that RequestContactMethodValidateCode command. I missed that that was for the primary as well.

Unfortunately checking whether or not it's the secondary in auth won't work because we use the same logic to send magic codes, as well as send validate codes, which shouldn't really be the case... But as it is, it may be tricky to split this up into the different cases (Magic code primary login, magic code secondary login, validation primary login, validation secondary login). I'll give it another go later today or more likely next week.

[arosiclair]

CP request here

[arosiclair]

Unfortunately checking whether or not it's the secondary in auth won't work because we use the same logic to send magic codes, as well as send validate codes, which shouldn't really be the case...

IIRC "magic codes" and "validate codes" are all the same thing so I don't think we need to change any logic. Just change the email template depending on if its primary/secondary. I might be wrong though. @johnmlee101 or @NikkiWines would probably be helpful.

[dangrous]

yeah it's more about the emails - I had managed to get the right one sent out for three out of the four cases, but missed the fourth one.

[NikkiWines]

Yeah, there isn't really a difference between magic codes and validate codes - it's just newer and older terminology. Unsubscribe codes and the CTA codes are distinct though as they aren't time limited

[arosiclair]

This was already fixed on staging so we should be all set