Skip to content

refactor(archiver): run log store reads in readOnlyTransaction - #442

Draft
spalladino wants to merge 3 commits into
spl/faster-logs-by-tagsfrom
spl/log-store-read-only-snapshots
Draft

spalladino wants to merge 3 commits into
spl/faster-logs-by-tagsfrom
spl/log-store-read-only-snapshots

Conversation

@spalladino

@spalladino spalladino commented Oct 9, 2026 •

Copy link
Copy Markdown
Collaborator

Stack

Bottom to top, each PR targets the branch below it:

Context

Part of A-1817. Redoes AztecProtocol/aztec-packages#25315 (closed after the repo split), adapted to the stubbed readOnlyTransaction.

Approach

  • LogStore read paths (getPrivateLogsByTags, getPublicLogsByTags, getPrivateLogsForBlock, getPublicLogsForBlock) use db.readOnlyTransaction instead of db.transactionAsync. Behavior is unchanged today; once A-2377 wires the native snapshot these reads stop queuing behind checkpoint ingestion with no further call-site changes.
  • LMDB reader-table size is configurable via DATA_STORE_MAX_READERS (dataStoreMaxReaders, default 16, as before). Values below 2 are rejected: the store reserves one reader slot, so 1 left cursors with zero permits and hung every scan.

The original PR's assertion that a tag query does not wait for queued writes is deferred to A-2377, since it can't hold until reads run on native snapshots.

`createStore` hardcoded 16 LMDB readers. It now reads `dataStoreMaxReaders` (`DATA_STORE_MAX_READERS`) from the
data store config, defaulting to the same 16. Every concurrent cursor holds a reader slot, so this bounds how many
reads a store can have in flight at once.
The log store's read paths (`getPrivateLogsByTags`, `getPublicLogsByTags`, `getPrivateLogsForBlock`,
`getPublicLogsForBlock`) now run in `db.readOnlyTransaction` instead of `db.transactionAsync`, keeping the same
one-consistent-view guarantee. `addLogs` and `deleteLogs` are unchanged.

`readOnlyTransaction` is still backed by `transactionAsync` on every backend, so behavior is unchanged for now: on
lmdb-v2 tag queries still wait for queued writes. Once the lmdb-v2 implementation is backed by a native read-only
LMDB transaction, these queries stop queueing behind block ingestion without further changes here.
The store keeps one reader back for point reads and hands the rest to cursors, so `maxReaders` of 1 left no cursor
slot and every iteration waited forever. `AztecLMDBStoreV2` now rejects a `maxReaders` that is not an integer of at
least 2 before opening the native store, which covers `DATA_STORE_MAX_READERS` and programmatic configs alike, and
the local signer config schema enforces the same bound.

This branch has not been deployed

No deployments
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