Skip to content

chore: forward port sqlite changes - #24947

Merged
mverzilli merged 5 commits into
merge-train/fairiesfrom
martin/forward-port-sqlite-changes
Jul 23, 2026
Merged

chore: forward port sqlite changes#24947
mverzilli merged 5 commits into
merge-train/fairiesfrom
martin/forward-port-sqlite-changes

Conversation

mverzilli and others added 5 commits July 23, 2026 16:58
)

Changes store management so that changes in rollup addresses and schema
versions cause different stores to be used. Previously we only supported
one store to be present at a time, which meant any version or rollup
change wiped pre-existing stores (note this includes network changes).

An underlying design decision in this PR is to strip the kv-store
package from responsibility over location on disk, knowledge about
rollup addresses, etc, at least as as regards PXE and wallet storage.
Other users of LMDB-v2 should not be impacted by this change.

In consonance, IndexedDB and SQLite backends drop their `createStore`
functions, which shoehorned wallet and PXE store creation to an
homogeneous interface that made it hard to let them independently
evolve.

Since we're changing this, I decided to also include the chain id as a
component of the store id, in addition to the already present schema
version and rollup address. It's not clear that we'll ever work on a
testnet or a different L1, but doing so is trivial and removes the need
to deal with this in the future.

Closes F-809

(cherry picked from commit 0bb0628)
Fixes a flake on the SQLite db management browser tests.

(cherry picked from commit af3323b)
Managed to corrupt my DB 🤷

(cherry picked from commit 007dcc2)
Prevents multi-tab concurrency issues in SQLite store creation by
guarding it with weblocks.

Closes F-829

(cherry picked from commit 386f120)
This is a defensive measure in case more than one SQLite page file is
found pointing to the same logical name, which could cause undefined
behavior. This could happen with old, pre-weblock controlled versions of
wallet/pxe (see
#24740), so it's
unlikely to be found in the wild, but it gives us graceful coverage if
that happens.

We detect if a pool contains two valid .opaque files mapped to the same
logical SQLite path, then:

  1. Acquire the pool Web Lock.
2. Copy the entire pool byte-for-byte into:
.aztec-sqlite-quarantine/<timestamp-random>/
  3. Verify the copied directory and file contents.
  4. Write a quarantine.json describing the duplicate mappings.
  5. Delete the original active pool.
  6. Open a new, empty database under the original pool name.
  7. Emit a warning log containing the quarantine location.

The caller receives a successfully opened but empty store, so wallet/PXE
state would need to be recreated or resynchronized. The quarantined
bytes remain available for forensic or manual recovery, although there
is currently no public API or UI for that.

If copying or verification fails, opening fails and the original pool is
not intentionally removed. If the pool merely comes from an old version
but has no duplicate logical mappings, nothing special happens, it opens
normally.

---------

Co-authored-by: Gregorio Juliana <gregojquiros@gmail.com>
(cherry picked from commit cfbd62a)
@mverzilli
mverzilli requested review from Thunkar and nchamo July 23, 2026 17:26
@mverzilli
mverzilli enabled auto-merge (squash) July 23, 2026 17:30
@mverzilli
mverzilli merged commit 438f2d7 into merge-train/fairies Jul 23, 2026
12 checks passed
@mverzilli
mverzilli deleted the martin/forward-port-sqlite-changes branch July 23, 2026 17:59
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.

3 participants