Reproduction
- Instance has password as first factor,
email_code as the (only) required second factor / MFA strategy.
- Render prebuilt
<SignIn routing="path" path="/sign-in" signUpUrl="/sign-up" /> (no custom flow).
- Submit correct password. First factor passes cleanly (no duplicate here).
- Sign-in transitions to
needs_second_factor. Two email_code verification emails arrive ~1 second apart; the first code is invalidated by the second.
Dashboard log evidence (single sign_in_id, single client)
sign_in.attempt_first_factor.passed strategy=password (T+0.0s)
sign_in.email_address.verification_code_sent (T+0.0s) <- code #1
sign_in.prepare_second_factor.passed strategy=email_code, new verification_id (T+0.0s)
sign_in.email_address.verification_code_sent (T+1.0s) <- code #2, invalidates #1
Same sign_in_id, same client_id, same IP across all four events — this is one browser tab, one attempt, not a remount/refresh or a second tab.
Why this looks like a sibling of #8463, not a duplicate report
#8463 (closed, "fixed in Core 3") and #8684/#4324 are about prepareFirstFactor / SignUp.create() re-sending a code on remount or because create() already prepares under the hood before an explicit prepare call fires again.
This reproduces on @clerk/react@6.12.9 (Core 3, current latest), with no remount involved — it's the transition from first-factor success straight into the second-factor (MFA) step, in a single mount. It looks like the same class of bug (backend/widget both send a code for the same verification step) but on the prepareSecondFactor code path specifically, which doesn't appear to have been covered by the Core 3 fix for the first-factor case.
Expected behavior
When a sign-in transitions to needs_second_factor and email_code is the strategy, <SignIn> should resume on whatever verification the backend already prepared for that transition (if any) rather than unconditionally calling prepareSecondFactor() again. A second code should only be sent when the user explicitly clicks "Resend."
Environment
@clerk/react: 6.12.9
- React: 19, Vite 6
pk_test_* instance, password + email_code (as second factor/MFA) enabled
- Reproduces in Chrome (desktop), consistently, every sign-in attempt requiring the second factor
Related
Reproduction
email_codeas the (only) required second factor / MFA strategy.<SignIn routing="path" path="/sign-in" signUpUrl="/sign-up" />(no custom flow).needs_second_factor. Twoemail_codeverification emails arrive ~1 second apart; the first code is invalidated by the second.Dashboard log evidence (single sign_in_id, single client)
Same
sign_in_id, sameclient_id, same IP across all four events — this is one browser tab, one attempt, not a remount/refresh or a second tab.Why this looks like a sibling of #8463, not a duplicate report
#8463 (closed, "fixed in Core 3") and #8684/#4324 are about
prepareFirstFactor/SignUp.create()re-sending a code on remount or becausecreate()already prepares under the hood before an explicitpreparecall fires again.This reproduces on
@clerk/react@6.12.9(Core 3, currentlatest), with no remount involved — it's the transition from first-factor success straight into the second-factor (MFA) step, in a single mount. It looks like the same class of bug (backend/widget both send a code for the same verification step) but on theprepareSecondFactorcode path specifically, which doesn't appear to have been covered by the Core 3 fix for the first-factor case.Expected behavior
When a sign-in transitions to
needs_second_factorandemail_codeis the strategy,<SignIn>should resume on whatever verification the backend already prepared for that transition (if any) rather than unconditionally callingprepareSecondFactor()again. A second code should only be sent when the user explicitly clicks "Resend."Environment
@clerk/react:6.12.9pk_test_*instance, password + email_code (as second factor/MFA) enabledRelated