[@clerk/react v6] <SignIn> sends duplicate email_code on second-factor (MFA) step, distinct from #8463

Inizia con il flusso predefinito @clerk/react e la transizione da needs_second_factor dopo il successo della password. Traccia dove viene chiamato prepareSecondFactor() e confrontalo con la verifica preparata dal backend mostrata negli eventi del dashboard. Riproduci il caso con password plus email_code MFA, quindi conferma che solo un Resend esplicito invia un altro codice.

Reproduction

1. Instance has password as first factor, email_code as the (only) required second factor / MFA strategy.
2. Render prebuilt <SignIn routing="path" path="/sign-in" signUpUrl="/sign-up" /> (no custom flow).
3. Submit correct password. First factor passes cleanly (no duplicate here).
4. 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

• #8463 (first-factor/remount case, closed as fixed in Core 3 — this is a different code path)
• #8684, #4324 (SignUp / prepareFirstFactor variants of the same "double prepare" pattern)