fix(client): keep concurrent connect() alive across reconnect

[chybisov]

Follow-up to #66 / #67.

Problem

reconnect runs on mount and polls each connector for a provider for up to 5s (retryUntil, 5000ms), so it is commonly in flight for several seconds on every page load. A user can complete a manual connect() inside that window.

When no connector reconnected, the tail reset fired unconditionally and wiped that fresh connection:

if (!connected) {
  config.setState((x) => ({ ...x, connections: new Map(), current: null, status: 'disconnected' }))
}

The user ends up disconnected immediately after successfully connecting.

Fix

Gate the reset on the store still being in the state reconnect put it in, so it only clears what reconnect itself owns:

const isStillReconnecting =
  config.state.status === 'reconnecting' || config.state.status === 'connecting'

if (!connected && isStillReconnecting) { /* reset */ }

This is wagmi's guard ("Prevent overwriting connected status from race condition"), the one piece of that block #66 did not port. Both interleavings are safe: if connect() finishes first the status is connected and the reset is skipped; if it is still in flight the status is connecting, the reset clears an empty map, and connect() then writes its own state on top.

Tests

Restores the @bigmi/client vitest setup and unisat.spec.ts that were added and then removed within #67 — the specs pass unchanged against the merged code. Adds reconnect.spec.ts covering:

• the stale rehydrated connection being replaced (regression test for Reconnect leaks stale connections on reload, dead connector stubs pile up #65)
• connections/current reset when nothing reconnects
• the race above — a deferred authorization check holds reconnect open while connect() lands; verified to fail without the guard and pass with it

pnpm test now covers @bigmi/client as well: 6 passed (client), 32 passed / 1 skipped (core).

Considered and rejected

Making current deterministic under parallelism (first-to-resolve wins rather than first in sorted order, so recentConnectorId priority is best-effort). Both implementations — rank tracking shared across parallel tasks, or a post-hoc re-pick — add a second synchronicity invariant to already-subtle code, and the loser is still a live connector. Not worth the complexity; happy to revisit if multi-wallet users report it.

Validation

pnpm check, pnpm check:types, pnpm check:circular-deps, pnpm knip:check, pnpm test all pass.

[changeset-bot]

🦋 Changeset detected

Latest commit: c895e02

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@bigmi/client	Patch
@bigmi/react	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR