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 #9006

Preliminary Checks

• I have reviewed the documentation: https://clerk.com/docs

• I have searched for existing issues: https://github.com/clerk/javascript/issues

• I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)

• This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.

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

• @clerk/[email protected]
• @clerk/[email protected]
• [email protected]
• Default import: import { useSignIn } from '@clerk/nextjs' (Future API, not /legacy)

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.