refactor(mempool): make mempool lock poisonable#2103
Open
kkovaacs wants to merge 2 commits into
Open
Conversation
kkovaacs
added
the
no changelog
Currently if a mempool operation panics, its possible to leave the mempool in a corrupted state. This PR changes mempool locking to poisonable, meaning that after a panic with the mempool lock held the corrupted mempool cannot be accessed. (For example, if add transaction panics, then subsequent block and batch building should not proceed.) Changed behavior: - `SharedMempool` now uses `std::sync::Mutex`. - `SharedMempool::lock()` returns `Result<MutexGuard<_>, MempoolPoisonError>`. - RPC submit/subscription paths map poison to internal errors. - Batch/block builders propagate poison as fatal. - Mempool-only helper methods are synchronous; `commit_block` remains async for store I/O. Closes #2016
kkovaacs
force-pushed
the
krisztian/mempool-poison
branch
from
6f9e774 to
ab54543
Compare
kkovaacs
force-pushed
the
krisztian/mempool-poison
branch
from
47c4a38 to
f6d9938
Compare
sergerad
reviewed
May 21, 2026
| let shared_mempool = self.mempool.lock().await; | ||
| // We need the let binding here to avoid E0597 `shared_mempool` does not live long enough | ||
| let result = shared_mempool | ||
| .lock() |
Collaborator
There was a problem hiding this comment.
Are we intentionally keeping a nested mutex here?
sergerad
approved these changes
May 21, 2026
Collaborator
sergerad
left a comment
sergerad
left a comment
There was a problem hiding this comment.
LGTM but I'm wondering about design of the nested mutex (predates this PR).
mempool: Mutex<SharedMempool>,
// ...
pub struct SharedMempool(Arc<Mutex<Mempool>>);
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
2 participants
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.
Currently if a mempool operation panics, its possible to leave the mempool in a corrupted state. This PR changes mempool locking to poisonable, meaning that after a panic with the mempool lock held the corrupted mempool cannot be accessed. (For example, if add transaction panics, then subsequent block and batch building should not proceed.)
Changed behavior:
SharedMempoolnow usesstd::sync::Mutex.SharedMempool::lock()returnsResult<MutexGuard<_>, MempoolPoisonError>.commit_blockremains async for store I/O.Closes #2016