Repository navigation
Reuse recovery config helper and document needsRecovery - #352
Merged
Merged
Conversation
Comment, docs and reuse cleanups around the single-owner embedded recovery; no behaviour change. - Replace the three inlined copies of the buildRecoveryParams config (useAutoRecovery and both call sites in useConnectToWalletPostAuth) with buildClientRecoveryConfig, which returns the same object. - Rewrite the comment on the embeddedState !== READY guard in useConnectToWalletPostAuth to state why the guard holds: the state is captured at render, a failed auto-recovery surfaces as recoveryError instead of signing the user out, and the login promise does not block on a passkey ceremony or an encryption-session fetch. - Correct the singleRecoveryPerLogin docblock: recovery is requested from three places, the post-authentication connect path being the third. - Add JSDoc to SetActiveEmbeddedWalletSuccess.needsRecovery, matching the note in openfort-xyz/documentation#493. No changeset: the behaviour these describe ships in the pending single-owner-embedded-recovery changeset for 2.1.3. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
commit: |
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four small cleanups around the single-owner embedded recovery that shipped in #347, #349 and #350. Comments, docs and reuse only — no behaviour change.
1. Reuse
buildClientRecoveryConfigactions/buildClientRecoveryConfig.tsreturns{ walletConfig, getAccessToken, getUserId }bound to a client. That same object literal was inlined verbatim in three places; each now calls the helper instead:openfort/hooks/useAutoRecovery.tshooks/openfort/auth/useConnectToWalletPostAuth.ts(the create path and the recover path)2. Rewrite the comment on the
embeddedState !== READYguarduseConnectToWalletPostAuthskips recovery when the embedded state is not READY. The comment now states why the guard holds, describing only the code as it stands:embeddedStateis captured at render through theuseCallbackdeps, so on a fresh login the guard stores the intended address and lets the provider's auto-recovery effect recover it. A failure there surfaces asrecoveryError, which the CreateWallet and Recover pages read to offer a new wallet on a new device, whereas a failure insidetryUseWalletreaches its own catch and signs the user out. It also keeps the login promise from blocking on a passkey ceremony or an encryption-session fetch; the modal shows progress instead.3. Correct the
singleRecoveryPerLogindocblockIt said recovery is requested from two places on a single login. There are three: the provider's auto-recovery effect, the modal's recover page through
setActive, and the post-authentication connect path (useConnectToWalletPostAuth). No test code changes.4. Document
needsRecoverySetActiveEmbeddedWalletSuccess.needsRecoverynow has JSDoc:truewhen activating the wallet needs a credential the caller has to collect first (a password),falseonce the signer holds the wallet. A wallet the signer already holds reportsfalsewithout any credential being collected or validated, sosetActiveis not a way to verify a user's password. Wording agrees with openfort-xyz/documentation#493.No changeset
This PR adds no behaviour. What items 2–4 describe already ships in the pending
.changeset/single-owner-embedded-recovery.mdfor 2.1.3.Checks
pnpm check,pnpm check:typesandpnpm test:unit(890 passing, unchanged) all pass.🤖 Generated with Claude Code