Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

`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

オープン
  • 何か問題がありますか？
#9,006 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
nextjs, typescript
領域
authentication

調査の方向性

Future useSignIn() のエントリポイントと signIn.reset()/clerk.client.resetSignIn() のパスから開始し、passkey を閉じるフローを再現してから、直ちに sso() を呼び出します。reset が新しい空の SignInFuture を公開または伝播し、その結果、後続の sso() が __internal_future に依存せずに OAuth を開始してナビゲーションすることが完了条件です。

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
TypeScript
スター
1.8k
フォーク
473
平均マージ
2日 3時間
マージ済み PR（30日）
269

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

clerk/javascript のほかの issue

clerk/javascript の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。