Skip to content

fix(store/state): perform potentially blocking RocksDB access in a blocking context#2076

Open
kkovaacs wants to merge 3 commits into
nextfrom
krisztian/move-store-rocksdb-access-to-blocking-tasks
Open

fix(store/state): perform potentially blocking RocksDB access in a blocking context#2076
kkovaacs wants to merge 3 commits into
nextfrom
krisztian/move-store-rocksdb-access-to-blocking-tasks

Conversation

@kkovaacs
Copy link
Copy Markdown
Contributor

@kkovaacs kkovaacs commented May 14, 2026

This PR moves runtime access to RocksDB-backed store state structures onto Tokio’s blocking path via block_in_place().

  • Added blocking helpers for State::inner and State::forest lock access.
  • Routed account/nullifier tree reads, tree mutation computation, tree mutation application, and account state forest reads/writes through those helpers.
  • Kept storage_map_key_cache updates on the normal async path since they do not touch the RocksDB-backed forest. Likewise, blockchain operations are entirely in-memory, so those too are left in async context.

Using block_in_place() is required because using spawn_blocking() would require the closure to be 'static, which in turn would require having an additional Arc wrapper around inner and forest.

Closes #1969

kkovaacs added 3 commits May 14, 2026 13:58
…king task

The account and nullifier trees may be backed by `RocksDB`, so tree access
must not run on an async worker thread directly.
The account state forest may be backed by `RocksDB`, so access must not
run on an async worker thread directly.
@kkovaacs kkovaacs marked this pull request as ready for review May 14, 2026 13:33
Copy link
Copy Markdown
Collaborator

@Mirko-von-Leipzig Mirko-von-Leipzig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine ito code, I'm just a bit concerned that we're using block_in_place? Should these be spawn_blocking?

Comment on lines +147 to +148
tokio::runtime::Handle::current()
.block_on(db_update_task)?
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be using block_on? I guess we're sort of saved because we know this will only happen once, and always sequentially?

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.

rocksdb access is blocking

2 participants