[Claudius-Maginificent]

Basic explanation

TL;DR: Restore each wallet's Platform balances and Core state from one consistent point in time, even when another process updates the wallet during startup.

Value: Startup returns matching balances, registrations and sync progress.

Risks: Three additional reads run within the existing per-wallet write reservation; concurrent writers wait or retry. No consensus or schema change.

User story

As a wallet user, I want startup to restore matching balances and sync progress, so that I do not see a mixture of old and new wallet data.

Scenario

Base flow

A wallet starts while another process writes an updated balance and sync progress to its database.

Actual behavior

Startup can combine an older Platform checkpoint with newer balances, account registrations and Core progress. A failed Core restore can also leave that wallet's Platform half in the returned result.

Expected behavior

Each restored wallet is internally consistent. If the wallet cannot be restored, neither half is returned.

Detailed discussion

Issue being fixed or feature implemented

Addresses 5150-10, the Platform snapshot review comment on #5150. This is a separate follow-up stacked on #5210, base feat/sqlite-wallet-restore; the prerequisite is not claimed to be merged.

What was done

Move Platform checkpoint, registration and address reads into the existing per-wallet SQLite IMMEDIATE transaction used for Core reconstruction. Publish both returned states only after successful reconstruction. Reuse typed decoders and preserve Strict/Recovery behavior, raw address counts including unregistered accounts, and rejection of unattributable corrupt wallet IDs.

The query budget increases by three targeted reads per wallet. Existing linear-cost and shared-overhead checks remain. No schema, dependency, financial-policy or public persister-contract changes.

How Has This Been Tested?

• Deterministic regression tests use an actual second SQLite connection: the writer is busy during load, the old dataset is coherent, a later write succeeds, and the next load returns the coherent new dataset. Both Strict and Recovery are covered.
• 39 selected integration tests pass, including corruption isolation, raw counts, typed pool restore, funded/reserved keys and pending sends.
• One additional unit test confirms that both Platform registration readers reject a mismatched key class with the existing typed error (40 passing tests in total).
• Storage Clippy with CI flags (--all-features --all-targets -- --no-deps -D warnings), formatting and diff checks pass.
• Detailed evidence and exact source provenance. No live/network tests or full workspace run.

Breaking Changes

None.

Checklist:

• I have performed a self-review of my own code
• My Rust changes follow the coding conventions
• I have commented code where the reason is not evident
• I have added relevant regression tests
• Relevant documentation and query-cost expectations are updated
• Independent review completed by a separate reviewer
• Milestone assigned by the coordinator

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[thepastaclaw]

🕓 Review not started yet because this PR is a draft.

• Request normal review — click when the PR is ready for review.
• Request priority review — click to move this review to the front of the queue.

Commit 1e407fc. Normal review starts when eligible; priority review starts as soon as a slot is available.