Skip to content

fix(bitcoin-wallet-snap): repair drifted wallets with a one-time full rescan - #226

Open
jeremytsng wants to merge 2 commits into
fix/btc-snap-reveal-at-signfrom
fix/btc-snap-one-time-rescan
Open

fix(bitcoin-wallet-snap): repair drifted wallets with a one-time full rescan#226
jeremytsng wants to merge 2 commits into
fix/btc-snap-reveal-at-signfrom
fix/btc-snap-one-time-rescan

Conversation

@jeremytsng

Copy link
Copy Markdown
Contributor

Explanation

Last of three PRs splitting #201 per review feedback. Stacked on #225.

The wide address scan runs exactly once in an account's life — at creation. A wallet whose funds landed outside the revealed set before the reveal-at-sign fix (#225) stays wrong forever; nothing in the product re-searches. Two support cases (0.09 BTC and 6.9 BTC) sat in exactly that state until the users recovered manually.

This PR adds a one-time repair, deliberately not a recurring job:

  • The first regular sync after this update schedules one full scan per existing account (FullScanAccount background events), then sets a rescanV1 state marker and never repeats. The scan uses the BIP44 gap from fix(bitcoin-wallet-snap): use BIP44 gap limit for full account scans #224.
  • Ordering is deliberate: schedule first, mark after. A crash mid-loop causes duplicate scans on retry — idempotent and bounded — instead of silently losing the repair.
  • Repair scans emit a Scan Discovered Missed Transactions tracking event per transaction routine sync did not know about. This is the acceptance metric for the stack: its rate should go to zero. Creation-time scans do not emit it, so expected discovery never pollutes the signal.
  • Cleanup along the way: the duplicated settle-aggregation block in CronHandler became one typed #finishSync helper, removing a Record<string, any>.

Recurring coverage (periodic rescans, all-account sync) is out of scope pending an infra discussion on Esplora load: a recurring full scan costs roughly 40 requests per account per run across the fleet, and the drifted-wallet population is a one-time problem.

References

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've communicated my changes to consumers by updating changelogs for packages I've changed
  • I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

… rescan

A full scan runs only once in an account's life, at creation, so a
wallet whose funds landed outside the revealed set stays wrong forever.
The first regular sync after this update schedules one full scan per
existing account, gated by a rescanV1 state marker set after scheduling
so a crash retries with duplicate scans instead of silently skipping
the repair. Repair scans emit a Scan Discovered Missed Transactions
tracking event for each transaction routine sync did not know about,
which measures whether the coverage fixes hold in the field.
@jeremytsng
jeremytsng requested a review from a team as a code owner August 27, 2026 17:32
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.

1 participant