Sign in - Single button press sends 4-5 magic code emails

[grgia]

Version Number: 9.4.32-0
Reproducible in staging?: Yes
Reproducible in production?: Unknown, believed to be a staging regression
If this was caught during regression testing, add the test name, ID and link from BrowserStack: N/A
Email or phone of affected tester (no customers): georgia+merge5@expensifail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @grgia
Slack conversation: #fireroom-2026-07-08-notifications-broken

Action Performed:

1. Go to staging.new.expensify.com while signed out
2. Enter an email address and press the sign in button once
3. Check the inbox for that account

Expected Result:

One magic code email is sent

Actual Result:

4-5 magic code emails arrive for the single button press. Logs confirm the client sends one BeginSignIn followed ~1 second later by 4-5 parallel RequestNewValidateCode API calls (within 5ms of each other, same deviceID). The backend correctly sends one email per request, so the duplication is client-side. The resendValidateCode throttle (maxAttempts 5) is the only thing capping the email count.

Workaround:

Yes, sign in works normally with the most recent code. The extra emails are noise.

Platforms:

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

Screenshots/Videos

Screen.Recording.2026-07-09.at.14.35.44.mov

[melvin-bot]

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

[melvin-bot]

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

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

[OSBotify]

🔍 Investigation Summary

Classification: Undetermined — leaning Backend bug (no App PR in this staging deploy touches the sign-in / RequestNewValidateCode path)
Causing PR: None identified with confidence. The client-side sign-in code is byte-for-byte identical between production and staging (see analysis).
Related Issues: None confirmed

Recommendation: NEEDS INVESTIGATION

The symptom is client-side (4-5 parallel RequestNewValidateCode calls), but no App PR in the 9.4.32-0 staging deploy modifies the sign-in flow, the resend/RequestNewValidateCode code, the login form, the countdown, or the network/queue/retry layers — the sign-in client code is unchanged vs production. I could not confirm a causing PR (frontend or backend), so I am keeping all labels and tagging the reporter for more context (e.g., confirmation of production reproducibility and the raw request logs).

Assigned: No causing PR identified — no new assignees added. cc @grgia (reporter) for the request logs / production repro confirmation.
Labels: No changes. DeployBlockerCash was added by an internal employee (@grgia) and production reproducibility is Unknown, so per policy the blocker label is retained.

📋 Detailed Analysis

Evidence

• Repro platform: MacOS Chrome (web / NewDot). Mobile-Expensify (HybridApp) changes are therefore not in play.
• Reported behavior: One BeginSignIn, then ~1s later 4-5 parallel RequestNewValidateCode calls within 5ms of each other, same deviceID. The report states the backend correctly sends one email per request, so the duplication is characterized as client-side.
• Key finding — the client sign-in code did not change on staging. Comparing production...staging, the ONLY file in the entire sign-in / session / network / validate-code surface that changed is src/pages/signin/ValidateCodeForm/BaseValidateCodeForm.tsx, and the change is a cosmetic lint fix that cannot cause duplicate requests:

  -                                medium
  +                                size={CONST.ICON_SIZE.MEDIUM}

  (from PR [No QA] - Fix cold lint after deprecating icons sizing #95606 "Fix cold lint after deprecating icons sizing").
• These files are NOT in the production...staging diff, i.e. they are identical to production:
  • src/libs/actions/Session/index.ts (beginSignIn, resendValidateCode → RequestNewValidateCode)
  • src/pages/signin/LoginForm/BaseLoginForm.tsx (submit guard isLoading.current)
  • src/components/ValidateCodeCountdown/index.tsx
  • src/libs/Network/MainQueue.ts, enhanceParameters.ts
  • No request/retry/reauthentication middleware changes (only src/libs/Middleware/FraudMonitoring.ts, which is an unrelated RevealExpensifyCardDetails → RevealExpensifyTravelCardDetails rename).
• The nitro-fetch fetch-layer change (feat: Enable react-native-nitro-fetch (V2) #94469, which could plausibly affect request duplication) was reverted on July 3 (commit d48b490a) and is not part of this staging build.

Verification

• Affected feature: passwordless sign-in — BeginSignIn followed by RequestNewValidateCode.
  • RequestNewValidateCode is dispatched by resendValidateCode in src/libs/actions/Session/index.ts (API.write(WRITE_COMMANDS.REQUEST_NEW_VALIDATE_CODE, ...)).
  • On the sign-in page it is only invoked from src/pages/signin/ValidateCodeForm/BaseValidateCodeForm.tsx (manual "resend" press) and src/pages/signin/ChooseSSOOrMagicCode.tsx (SSO accounts) — neither auto-fires on the plain email + button repro.
• Confirmed via gh api repos/Expensify/App/compare/production...staging that none of the PRs in deploy checklist Deploy Checklist: New Expensify 2026-07-09 #95677 modify the above code paths. Session/index.ts, LoginForm, ValidateCodeCountdown, and the network layer are all absent from the diff (= unchanged from production).
• The App-side files that DID change (src/libs/actions/User.ts, src/libs/actions/App.ts, src/libs/API/types.ts) are unrelated: push-notification topmostOneTransactionThreadReportID plumbing, a ReconnectApp loading-flag fix, and the card-details command rename respectively.

Root Cause

Not conclusively determined. Because the client sign-in code is unchanged from production, a purely client-introduced staging regression is not supported by the diff. Two possibilities remain and need input from the reporter:

1. Backend / API change (outside this App repo) altering the BeginSignIn response or RequestNewValidateCode handling in a way that induces the client (unchanged code) to fire multiple requests, or duplicates them server-side. If so, the fix belongs in the backend and no App PR should be reverted.
2. A pre-existing latent client behavior (present on production too) surfaced during merge testing — the report lists production reproducibility as "Unknown". This would make it not a staging regression at all.

Requested next steps: (a) confirm whether the issue reproduces on production, and (b) share the raw request logs (the StackOverflow link) so we can see whether the duplicates originate from the App network queue or are backend-side. Since DeployBlockerCash was applied by an internal engineer and production repro is unconfirmed, the blocker label is intentionally retained.

[MelvinBot]

Proposal

Root Cause: An unguarded auto-resend useEffect on the onboarding "private domain" screen fires RequestNewValidateCode repeatedly as Onyx hydrates in the ~1s after BeginSignIn. In BaseOnboardingPrivateDomain.tsx:96-104 the effect calls sendValidateCode() on mount, gated only by isValidated and shouldBlockPublicDomain. All three of its dependencies are unstable across hydration — sendValidateCode is useCallback(…, [email]) where email = session?.email ?? '' starts empty and populates, isValidated reads loginList which hydrates late, and shouldBlockPublicDomain depends on account.validated/isFromPublicDomain. As SESSION, LOGINS, and ACCOUNT hydrate over ~1s, the effect re-runs on each change while the guards still evaluate false, firing 4-5 resendValidateCode(email) → REQUEST_NEW_VALIDATE_CODE calls within milliseconds. This exactly matches the reported symptom (one BeginSignIn, then 4-5 parallel RequestNewValidateCode within 5ms, same deviceID). There is no first-render / "already sent" guard here, unlike the sibling flow.

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

Make the auto-send fire at most once, and only after Onyx has hydrated — the exact pattern already used in ValidateCodeActionContent.tsx:42-59: a firstRenderRef guard combined with a wait for the relevant Onyx metadata to finish loading (and, ideally, the lastValidateCodeRequestedAt recency check so a reload within the resend window doesn't re-send). Applying that same guard to the BaseOnboardingPrivateDomain effect collapses the burst to a single email while preserving the intended "send a code when this screen opens" behavior.

Investigation details & evidence

Symptom → code match

• Reported: one BeginSignIn, ~1s later 4-5 parallel RequestNewValidateCode within 5ms, same deviceID; backend sends one email per request → duplication is client-side; the resendValidateCode throttle (maxAttempts 5) caps the count.
• A synchronous 4-5x burst within ms is the signature of a useEffect re-firing across renders due to unstable dependencies as multiple Onyx keys hydrate — precisely the shape of BaseOnboardingPrivateDomain.tsx:96-104, whose sendValidateCode is defined at :64-69.

Ruled out (not the source)

• The signed-out sign-in magic-code form src/pages/signin/ValidateCodeForm/BaseValidateCodeForm.tsx resends only on the manual button press (onCountdownFinish just stops the countdown; no mount auto-resend).
• The other auto-send-on-mount wrappers can't produce a 4-5 burst: ValidateCodeActionContent is properly guarded (firstRenderRef + hydration + recency), and ValidateCodeActionForm/index.tsx:30-39 is gated on a single boolean (shouldSkipInitialValidation), giving at most ~2 fires. Only BaseOnboardingPrivateDomain has the 3-unstable-dependency, unguarded pattern.
• resendValidateCode maps to REQUEST_NEW_VALIDATE_CODE via @userActions/User resendValidateCode → src/libs/actions/Session/index.ts.

Why staging regression: the screen's own comment at :92-93 describes the unvalidated public-domain user landing here as "the staging happy path," indicating this auto-send flow is recent. (Note: an earlier deploy-blocker pass that scanned only signin/ValidateCode/Session/User/Countdown PRs — not Onboarding — found no culprit; that scan didn't cover this file.)

Caveat / how to confirm (Medium confidence): The reporter's STR is a generic email sign-in. This screen only mounts for an unvalidated user (validated users hit isValidated → the guard returns early), which fits a fresh test account (+merge5). To pin it to 100%, check the client/Sentry breadcrumbs at the moment of the burst and confirm the Onboarding_Private_Domain route was mounted ~1s after BeginSignIn. If a different screen is active, the same unguarded-resend fix pattern still applies, but the target file would differ.

Related issues

No open duplicates found. #86498 touches the same onboarding "join existing policies" area but is a different symptom.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95705) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (App-side), but NOT a staging regression — the offending code is already live on production.
Causing PR: None in this release. The unguarded auto-resend useEffect predates this deploy (introduced no later than 2026-05-20; db992ccbd). The only release PR touching this file is #95001 — "fix: onboarding back button redirects to blank modal for private-domain VSB/SMB" by @dilshodmackbook-sketch (merged 2026-07-09), which is unrelated to the burst (High confidence it is NOT the cause).
Related Issues: None confirmed.

Recommendation: ROLL FORWARD (forward-fix, do not revert)

The root-cause code is byte-for-byte present on production, so there is nothing in this release to revert — a revert of #95001 would only undo an unrelated step-counter/back-button fix and would NOT stop the duplicate emails. A targeted forward-fix (add the existing firstRenderRef + hydration + lastValidateCodeRequestedAt recency guard to the BaseOnboardingPrivateDomain effect) is the correct path.

Assigned: No new assignees — no causing PR in this release, so per the single-PR assignment rule there is no author/reviewer to attach. cc @grgia (reporter).
Labels: No changes. DeployBlockerCash is retained — the bug is App-side (frontend), the label was applied by an internal employee (@grgia), and the offending code is confirmed present on production. Per policy I do not remove the App blocker when an App bug caused/contributed to the issue.

📋 Detailed Analysis

Root Cause (confirmed against code)

The 4-5 parallel RequestNewValidateCode burst comes from an unguarded auto-resend useEffect in src/pages/OnboardingPrivateDomain/BaseOnboardingPrivateDomain.tsx (lines 96-104):

useEffect(() => {
    if (shouldBlockPublicDomain) { return; }
    if (isValidated) { return; }
    sendValidateCode();               // -> resendValidateCode(email) -> REQUEST_NEW_VALIDATE_CODE
}, [sendValidateCode, isValidated, shouldBlockPublicDomain]);

All three dependencies are unstable while Onyx hydrates in the ~1s after BeginSignIn:

• sendValidateCode is useCallback(..., [email]) with email = session?.email ?? '' (SESSION key hydrates late).
• isValidated = isCurrentUserValidated(loginList, ...) (LOGINS hydrates late).
• shouldBlockPublicDomain reads account.validated / account.isFromPublicDomain (ACCOUNT hydrates late).

With no firstRenderRef/"already-sent" guard, the effect re-fires on each hydration tick → 4-5 resendValidateCode calls within ms, capped only by the maxAttempts 5 throttle. This matches the symptom exactly. The sibling src/components/ValidateCodeActionModal/ValidateCodeActionContent.tsx (lines 42-59) has the correct guard; it was never applied here.

Evidence this is NOT a staging regression (key finding)

• gh api repos/Expensify/App/compare/production...staging shows the only hunk for this file is a refactor of joinablePoliciesLength into getVisibleJoinablePoliciesCount(...). The auto-send useEffect, the sendValidateCode useCallback, and even the "...that's the staging happy path" comment all appear in the unchanged context of that diff.
• Fetching the file at ?ref=production returns the buggy effect and sendValidateCode callback verbatim (lines 63-104), including the "staging happy path" comment. The code is identical to staging apart from the joinablePoliciesLength refactor.
• File commit history (via gh api .../commits?path=...): the effect's dependency array was already being edited on 2026-05-20 (db992ccbd "Hide PrivateDomain merge screen from public-domain users" — its patch shows -}, [sendValidateCode, isValidated], i.e. the effect pre-existed that commit). The effect long predates the 9.4.32 release window.

Scope covered (prior pass had gaps)

The earlier automated pass scanned only signin/ValidateCode/Session/User/Countdown PRs and found nothing. I additionally covered Onboarding/OnboardingPrivateDomain/Welcome/OnboardingUtils/routing/resendValidateCode:

• Only release PR touching BaseOnboardingPrivateDomain.tsx is fix: onboarding back button redirects to blank modal for private-domain VSB/SMB #95001 (step-counter/back-button fix). Its file set is step-counter + OnboardingUtils helper extraction + BaseOnboardingEmployees; it does not touch the auto-send effect, its deps, sendValidateCode, or resendValidateCode.
• src/libs/OnboardingUtils.ts change is purely the extracted getVisibleJoinablePoliciesCount helper — no behavior change.
• No PRIVATE_DOMAIN route changes in src/ROUTES.ts or src/libs/Navigation/linkingConfig/config.ts, and no Welcome action change that would newly mount this screen during email sign-in. So the "routing now mounts this screen during sign-in" theory is not supported by this release's diff.
• src/components/ValidateCodeActionForm/index.tsx and ValidateCodeActionModal/* are unchanged in this release.

Why forward-fix over revert

Reverting has nothing to bite on — the causal code is on production and no in-release PR introduced or modified it. The clean fix is to gate the effect to fire at most once and only after hydration, reusing the guard pattern already present in ValidateCodeActionContent.tsx (firstRenderRef + wait-for-hydration + lastValidateCodeRequestedAt recency). This preserves the intended "send a code when this screen opens" behavior while collapsing the burst to one email.

Note for the deploy team

Because this is a pre-existing production bug rather than a 9.4.32 regression, it does not need to block this deploy on regression grounds — but as an App-side bug with an internal-applied DeployBlockerCash, I am leaving the label for a human owner to make the promote/demote call. If confirmed to reproduce on production (the code says it will for unvalidated users landing on this screen), DEMOTE + track a normal forward-fix is reasonable.

[dilshodmackbook-sketch]

I investigated whether #95001 caused the deploy blocker #95705 (single sign-in press sending 4-5 magic code emails).

It didn't. The burst comes from the unguarded auto-resend useEffect in BaseOnboardingPrivateDomain.tsx — its deps (sendValidateCode/isValidated/shouldBlockPublicDomain) all flip while SESSION/LOGINS/ACCOUNT hydrate in the ~1s after BeginSignIn, so it fires resendValidateCode once per hydration tick. That effect is untouched by #95001 and is byte-for-byte identical on production (9.4.31-0), so this is a pre-existing bug rather than a staging regression. The only change #95001 made to that file was replacing the inline joinablePolicies filter with the getVisibleJoinablePoliciesCount helper (same logic, doesn't feed the effect), and the step-counter/back-button changes only affect header UI and back navigation, not when the validate code is requested.

This matches the investigation summary on the blocker: nothing to revert, a forward fix (adding the same first-render/already-sent guard ValidateCodeActionContent uses) is the right path.