Skip to content

fix(monitoring): release chain_state write lock before RPC loop in check_chain_state#3271

Open
amathxbt wants to merge 1 commit into
chainwayxyz:nightlyfrom
amathxbt:fix/check-chain-state-write-lock-across-rpc
Open

fix(monitoring): release chain_state write lock before RPC loop in check_chain_state#3271
amathxbt wants to merge 1 commit into
chainwayxyz:nightlyfrom
amathxbt:fix/check-chain-state-write-lock-across-rpc

Conversation

@amathxbt

@amathxbt amathxbt commented May 3, 2026

Copy link
Copy Markdown

Closes #3268

Problem

check_chain_state acquires self.chain_state.write() before checking whether the tip has changed, then—inside the if tip_changed branch—performs up to finality_depth sequential async get_block_hash RPC calls while still holding the write lock. This is the same anti-pattern previously fixed in handle_evicted, monitor_transaction, check_transactions, and handle_reorg.

Holding the write lock for the full duration of the RPC loop:

  • Blocks all concurrent readers of chain_state for the entire round-trip window (latency spikes).
  • Risks deadlock when concurrent tasks that need a read lock are waiting on the same executor.

Fix

  1. Snapshot current_tip and recent_blocks under a short read lock, then release immediately.
  2. Perform all get_block_hash calls lock-free against the snapshot.
  3. Acquire the write lock only once, at the end, for the current_height / current_tip / recent_blocks update.

File changed: crates/bitcoin-da/src/monitoring.rs

…eck_chain_state

check_chain_state acquires a chain_state write lock at the top of its
if-branch and then performs up to finality_depth sequential async
get_block_hash RPC calls while holding that lock. This blocks every
concurrent reader of chain_state for the full duration of those
round-trips, introducing latency spikes and potential deadlocks under
load.

Fix mirrors the pattern applied in monitor_transaction, check_transactions
and handle_reorg: snapshot the data needed for the RPC loop under a
short read lock, release the lock, perform all RPC calls lock-free,
then re-acquire the write lock only for the final state update.
@amathxbt amathxbt requested a review from a team as a code owner May 3, 2026 09:27
@auto-assign auto-assign Bot requested a review from jfldde May 3, 2026 09:27
@amathxbt

amathxbt commented May 6, 2026

Copy link
Copy Markdown
Author

@jfldde @eyusufatik — reviewed this PR. No lint issues found. Ready for your review.

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.

fix(monitoring): check_chain_state holds chain_state write lock across async RPC loop

1 participant