fix(monitoring): release chain_state write lock before RPC loop in check_chain_state#3271
Open
amathxbt wants to merge 1 commit into
Open
Conversation
…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.
Author
|
@jfldde @eyusufatik — reviewed this PR. No lint issues found. Ready for your review. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #3268
Problem
check_chain_stateacquiresself.chain_state.write()before checking whether the tip has changed, then—inside theif tip_changedbranch—performs up tofinality_depthsequential asyncget_block_hashRPC calls while still holding the write lock. This is the same anti-pattern previously fixed inhandle_evicted,monitor_transaction,check_transactions, andhandle_reorg.Holding the write lock for the full duration of the RPC loop:
chain_statefor the entire round-trip window (latency spikes).Fix
current_tipandrecent_blocksunder a short read lock, then release immediately.get_block_hashcalls lock-free against the snapshot.current_height / current_tip / recent_blocksupdate.File changed:
crates/bitcoin-da/src/monitoring.rs