Deeplink-2FA code is requested for users without 2FA enabled when signing in via public room.

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.72-2
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176964/test-cases/41237765
Email or phone of affected tester (no customers): htad26+@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10 / Chrome
App Component: Other

Action Performed:

1. Log out of New Expensify
2. Navigate to a public room link - (you can use this one https://staging.new.expensify.com/r/1540486774487195)
3. Click on Sign In
4. Log in with an existing account that doesn't have 2FA set up
5. Enter magic code

Expected Result:

The user is signed in

Actual Result:

2FA recovery code is requested even if the user hasn't set up 2FA in their account

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7251482_1788550736460.bandicam_2026-09-04_22-36-54-604.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7251482

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/ee8070ff8517e02a554b40326d8c49163136d15a6b882fe8dc2c95b4ff9b386c

[melvin-bot]

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

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Backend bug (no App PR in this release touches the sign-in / 2FA flow)
Causing PR: None found in the v9.4.72 checklist — see the audit below (High confidence that no App PR in this release is responsible)
Related Issues: #100332 (StagingDeployCash checklist for 9.4.72-2)

Recommendation: NEEDS INVESTIGATION

I audited every PR on the 9.4.72 checklist and none of them modify sign-in, validate-code, 2FA, credentials, session, anonymous/public-room, or deeplink-transition code — the production...staging diff contains zero changes under src/pages/signin/**, src/libs/actions/Session/**, src/selectors/Account.ts, or src/types/onyx/Account.ts. Since the App only ever renders the 2FA/recovery-code step from the API-provided account.requiresTwoFactorAuth flag, and that code is byte-identical on staging and production, this looks like a backend/API regression on the staging API (staging.new.expensify.com talks to the staging API, which deploys independently of NewDot). This appears to be a backend/internal issue. A separate internal investigation is needed.

Labels: No changes. DeployBlockerCash is being kept — the issue is not reproducible on production, and it is the only blocker label on the issue, so removing it would unblock the deploy entirely on the basis of a negative (nothing-in-the-diff) result. If the backend team confirms the API is at fault, DeployBlocker should be added so the Web/API deploy is the one that's held.

📋 Detailed Analysis

Verification

The only place the App decides to show the 2FA / recovery-code step during sign-in:

• src/pages/signin/ValidateCodeForm/BaseValidateCodeForm.tsx#L328 — render gate: {account?.requiresTwoFactorAuth && !!credentials?.validateCode ? (
• src/pages/signin/ValidateCodeForm/BaseValidateCodeForm.tsx#L256-L257 — submit gate, same condition
• src/pages/signin/SignInPage.tsx#L279 — const isTwoFactorStage = account?.requiresTwoFactorAuth && !!credentials?.validateCode; (drives the header copy)

account.requiresTwoFactorAuth (src/types/onyx/Account.ts#L95) is never set client-side during sign-in. A grep over src/ shows only two local writes, neither on the sign-in path:

• src/libs/actions/Session/index.ts#L1370 — clears an errorFields entry
• src/libs/actions/Session/index.ts#L1452 — optimistic true when the user enables 2FA during forced onboarding

Everywhere else the value arrives via onyxData on the BeginSignIn / SigninUser responses. So the client is faithfully rendering what the API told it.

Evidence

git diff --name-only production...staging for this release returns 152 files. Filtering for anything auth-related returns only false positives (accounting "Account" pages and WorkspaceInvoicesVerifyAccountPage.tsx). Per-PR file audit of the whole checklist:

PR	Author	Area	Touches sign-in/2FA?
#95925 / #100354	lorretheboy / chuckdries	src/libs/actions/BankAccounts.ts (and revert)	No
#97813, #100357	ishpaul777	PDF receipt page badge	No
#97972	nabi-ebrahimi	Search Router workspace suggestions	No
#98419	marufsharifi	Statement close date picker	No
#98672	tgolen	531 bank connection messaging	No
#99025, #99867	allgandalf / MelvinBot	Accounting export pages	No
#99061	sosek108	ReportAlternateTextUtils	No
#99111	samranahm	Report action mini toolbar	No
#99279, #100314	MelvinBot / puneetlath	TransactionInlineEdit, Onyx hooks	No
#99308, #99842	MelvinBot	Report fields, Getting started	No
#99633, #99890	linhvovan29546 / elirangoshen	Report transactions	No
#99654	Gonals	Approval workflows	No
#99689	dilshodmackbook-sketch	Reports "Select all" label	No
#99743, #100124	jmusial / roryabraham	Typecheck / Jest tsconfig	No
#99776	jmusial	Workspace invoices VBA	No
#99818	cretadn22	conciergeChat Onyx.connect	No
#99829, #100356	s77rt	Accordion animation	No
#99920	mhawryluk	Pasted image MIME detection	No
#100022	adhorodyski	Home card totals Search	No
#100144	mukhrr	Search page cursor	No

Reproduces on staging only, not production — consistent with a staging-API-only change, since the NewDot sign-in code is identical on both branches (git diff production staging -- src/pages/signin src/libs/actions/Session is empty).

Root Cause

Most likely the staging API is returning requiresTwoFactorAuth: true in the onyxData of the sign-in response for an account that has no 2FA configured, when the sign-in is initiated from an anonymous/public-room session. The App then correctly-but-unhelpfully switches BaseValidateCodeForm to the 2FA/recovery-code input and blocks the user.

Next steps for whoever picks this up: grab the requestID from a failed repro on staging and check the SigninUser response payload for requiresTwoFactorAuth. If it is true for a non-2FA account, the fix is backend and this should be re-labelled as a Web/API deploy blocker. If it comes back false, then this is a client-side stale-Onyx problem in the anonymous → authenticated transition and the App-side investigation should be reopened — but note that path was not modified in this release either.

[MelvinBot]

🤖 Deploy blocker investigation: no App PR caused this

Conclusion: nothing in the v9.4.72 checklist can be reverted to fix this. The NewDot sign-in code on staging is byte-identical to production, so the difference is on the backend/API side. This appears to be a backend/internal issue — a separate internal investigation is needed.

Verified evidence (staging 6c6afc3, production 7d9090d):

git diff production staging -- src/pages/signin src/libs/actions/Session \
    src/types/onyx/Account.ts src/types/onyx/Credentials.ts
# → empty

The App only ever shows the 2FA/recovery-code step from the API-supplied account.requiresTwoFactorAuth flag:

• src/pages/signin/ValidateCodeForm/BaseValidateCodeForm.tsx:328 — render gate
• src/pages/signin/SignInPage.tsx:279 — isTwoFactorStage

That flag is never set client-side on the sign-in path, so the client is faithfully rendering what the API returned. Staging NewDot talks to the staging API, which deploys independently of NewDot — that explains staging-yes / production-no with identical frontend code.

Recommended next step: get a requestID from a staging repro and inspect the SigninUser / BeginSignIn response payload for requiresTwoFactorAuth when the sign-in originates from an anonymous/public-room session.

Labels: DeployBlockerCash kept — not reproducible in production, and removing it on a negative result would unblock the deploy outright. Once the backend team confirms, DeployBlocker should be added so the API deploy is the one held.

Scope of the audit & caveats

All 26 checklist PRs from #100332 (plus the 2 Internal QA PRs) were checked file-by-file. The production...staging diff is 152 files; the only auth-keyword matches are false positives (.../accounting/...Account...Page.tsx, WorkspaceInvoicesVerifyAccountPage.tsx, src/libs/actions/BankAccounts.ts). The full per-PR table is in the detailed comment above.

Confidence:

• "No App PR in this release caused it" — High. The negative diff is exhaustive and mechanical.
• "The API is returning a bad requiresTwoFactorAuth" — Medium-High. Inferred from the client code; not confirmed against a live response, since no requestID was attached to the report.

An automated web repro was attempted but could not run: the flow requires signing out and re-authenticating with a magic code, which the CI test harness cannot retrieve.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

---

view run · no recording available

[francoisl]

This looks like a backend thing, and https://github.com/Expensify/Web-Expensify/pull/55813 looks related. It was just deployed to staging today.

Going to mark this as a web blocker for further investigation