Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

`signIn.reset()` / `client.resetSignIn()` don't propagate a fresh empty SignIn to the Future `useSignIn()` hook, so `sso()` after reset reuses the stale resource and never navigates

Offen
  • Stimmt etwas nicht?
#9,006 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@RealBhupesh arbeitet bereits daran.

Seit 01.9.2026.

  • #9071 von @FrancoKaddour — ohne Merge geschlossen
  • #9629 von @RealBhupesh — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
nextjs, typescript
Bereich
authentication

Rechercherichtung

Beginne am Future useSignIn()-Einstiegspunkt und am Pfad signIn.reset()/clerk.client.resetSignIn(); reproduziere den Ablauf zum Verwerfen des Passkeys und rufe anschließend sofort sso() auf. Erledigt ist es, wenn reset ein neues leeres SignInFuture offenlegt oder weitergibt, sodass das nachfolgende sso() OAuth startet und navigiert, ohne sich auf __internal_future zu stützen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug clerk-js confirmed core-3
Preliminary Checks
Reproduction

https://github.com/clerk/javascript

Publishable key

pk_test_1234

Description

Summary

I'm using the Future custom-flow hooks (useSignIn() from @clerk/nextjs, not /legacy). When I reset an in-progress sign-in, the reset doesn't propagate a new empty SignInFuture resource to the hook's signIn. The only way I've found to get the live post-reset resource at call-time is the internal clerk.client.signIn.__internal_future. Your support team confirmed this: "our existing reset pathway doesn't result in the propagation of a new empty SignIn for the new hooks."

Environment

Reproduction

Custom SSO flow built on useSignIn():

  1. Leave an in-progress SignIn. Easiest way is to start a discoverable passkey (signIn.passkey({ flow: 'discoverable' })) and then dismiss the WebAuthn prompt, which persists a signIn with an id.
  2. In a single click handler, call await signIn.reset() (or clerk.client.resetSignIn()).
  3. Immediately call await signIn.sso({ strategy: 'oauth_google', redirectUrl, redirectCallbackUrl }).

Expected

sso() starts a fresh OAuth attempt and navigates to the provider.

Actual

sso() PATCH-continues the stale (pre-reset) SignIn and resolves without navigating, so the SSO button just hangs. The signIn reference captured in my handler's closure is the pre-reset one, and since the SignInFuture resource has an intentionally unstable identity and reset doesn't refresh the hook's value, the closure can never see the new resource within the same handler. A memo dep array only affects future invocations, not the one that's already running.

Workaround

I read the live resource at call-time from the internal field:

if (clerk.client?.signIn.id) clerk.client.resetSignIn();
const resource = clerk.client?.signIn.__internal_future ?? signIn;
await resource.sso({ ... });

This leans on __internal_future, which is internal and can break between minor versions, for what's otherwise a completely ordinary flow (reset a stale sign-in, then start SSO).

Suggested fixes (any one of these would let me drop __internal_future)

  • reset() resolves with the fresh SignInFuture resource, or
  • a public accessor for the live resource (something like clerk.client.signInFuture), or
  • reset() propagates a new empty SignIn to the useSignIn() hook so calling sso() on the hook's signIn works after a reset.
Environment
I was told by support I didn't need to provide any of this:
> Thanks for the info! I think the best way to follow this would be to file an issue on our GitHub repo for the JavaScript SDKs https://github.com/clerk/javascript. A minimal reproduction would be incredible if you can toss one together, but totally fine if not. I took a quick look and I do think you're right on the money that our existing reset pathway doesn't result in the propagation of a new empty SignIn for the new hooks.
Vorherrschende Sprache
TypeScript
Sterne
1.8k
Forks
480
Ø Merge
1 T. 19 Std.
Gemergte PRs (30 T.)
285

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus clerk/javascript

Alle Issues in clerk/javascript

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.