[condor-agent]

A returning user with existing embedded wallets was routed to wallet creation instead of recovery, and got a brand-new wallet on every login. Reported against @openfort/react@2.1.1 on Solana devnet; reproduced four times in that project's traffic, where GET /v2/accounts returned the full list (5, then 6, then 7 wallets, all owned by the same stable user) and was immediately followed by POST /v2/devices/create. Nothing was lost — the API answered correctly and the SDK threw the answer away.

Cause

On EMBEDDED_SIGNER_NOT_CONFIGURED, the state machine starts the user fetch and the account fetch concurrently. fetchEmbeddedAccounts captures sessionGenerationRef when it starts and drops its result if that generation moved by the time the response lands. publishAuthenticatedUser called invalidateSessionWork() on every publication, which bumps that generation and clears accountsPending.

/iam/v2/me answers in ~30 ms; /v2/accounts takes ~190 ms. The user publication therefore always won: the account list was discarded on arrival, isLoadingAccounts dropped to false before it, and LoadWallets evaluated an empty store and took the create route. Deterministic, not flaky — which is why it reproduced on every login.

Fix

Separate the two things the generation counter was conflating.

The comment on that line states the intent — "any publication supersedes an older user fetch still in flight" — and userFetchSeqRef is the guard that already covers exactly that. So a publication now bumps the user-fetch sequence only. A full session invalidation is reserved for a genuine change of principal, alongside the wallet-discarding work already in that branch.

This also stops an ordinary user refresh from tearing down persistent operations, which invalidateSessionWork did on every publication.

Two regression tests, both confirmed to fail when their guard is removed, per AGENTS.md:

• an account list in flight survives a same-principal publication, and isLoadingAccounts stays true until it lands;
• an account list in flight is still discarded when the principal changes.

Verification

pnpm check, check:types, test:types (889), test:unit (870), build, size and build:docs all pass.

Not exercised against a live browser session: the failure is a promise-ordering race inside the provider and is covered at that level, but a devnet sign-in through <OpenfortButton /> with an existing wallet is worth doing before release.

Prompted by: Joan Alavedra

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
playground	Ready	Preview	Sep 15, 2026 4:16pm UTC

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@openfort/react@342

commit: db50645