Skip to content

BOT-1359: Continue onboarding after key import#2056

Merged
baxen merged 1 commit into
mainfrom
bumble/bot-1359-existing-key-hang
Jul 17, 2026
Merged

BOT-1359: Continue onboarding after key import#2056
baxen merged 1 commit into
mainfrom
bumble/bot-1359-existing-key-hang

Conversation

@baxen

@baxen baxen commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

Why

Importing an existing key during first-launch onboarding publishes a new identity before the setup page renders. The machine gate treated that identity switch as unevaluated and replaced onboarding with a permanent loading screen.

What

  • Mark imported identities as intentional onboarding transitions before updating the identity cache
  • Keep the machine flow mounted through the identity switch so runtime setup can continue
  • Add first-launch key-import regression coverage

Risk Assessment

Low — scoped to explicit key imports while machine onboarding is active; cold-boot identity evaluation remains unchanged.

References

Generated with Bumble

Keep explicitly imported identities in machine onboarding so the setup step can render after the identity cache changes.

Co-authored-by: npub1t490dek5vslqxv0ft0jlft6j5fjlp74jery2tyj7ngf8ggd0pcnst8w25n <5d4af6e6d4643e0331e95be5f4af52a265f0fab2c8c8a5925e9a127421af0e27@sprout-oss.stage.blox.sqprod.co>
Signed-off-by: npub1t490dek5vslqxv0ft0jlft6j5fjlp74jery2tyj7ngf8ggd0pcnst8w25n <5d4af6e6d4643e0331e95be5f4af52a265f0fab2c8c8a5925e9a127421af0e27@sprout-oss.stage.blox.sqprod.co>
@baxen
baxen marked this pull request as ready for review July 17, 2026 23:37
@baxen
baxen requested a review from a team as a code owner July 17, 2026 23:37
@baxen
baxen merged commit 738d456 into main Jul 17, 2026
25 checks passed
@baxen
baxen deleted the bumble/bot-1359-existing-key-hang branch July 17, 2026 23:37

@baxen baxen left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No blocking findings. I independently reproduced the claimed race by running the new regression against the base implementation: the import succeeded, then the machine flow was replaced by the permanent app-loading-gate; the same test passes at this head.

The ordering in this patch is the right boundary: import_identity has already parsed, persisted, and installed the key before continueWithIdentity(identity.pubkey) runs, and the continuation is registered before React Query synchronously publishes that identity. The bypass is exact-pubkey scoped, while reset/locked/lost/relaunch stages retain higher precedence and ordinary cold boots still have a null continuation marker and take the existing evaluation path.

I also traced the marker lifecycle. Although the ref is process-lifetime, I don't see a current stale-marker path that alters behavior: completion writes a key-scoped completion flag, reopen explicitly marks the current key evaluated, a second machine import replaces the marker, failures never set it, and relaunch remounts the hook. Other in-app imports use the community-scoped QueryClient rather than this outer machine gate.

Independent validation at 0da894b40:

  • base-vs-head first-launch regression: base fails at the loading gate, head passes
  • full identity-lost.spec.ts: 8/8 pass (normal first launch, lost/locked recovery, re-import, relaunch)
  • extra focused scenarios: completion + reopen + reload, a second explicit import, and an injected backend import failure: 3/3 pass
  • TypeScript build/typecheck pass

Generated with Astro

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants