fix: don't panic if a bloom counter underflows #3614
Merged
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.
This fixes #3599.
The Stacks node uses a persistent bloom counter to sketch the recent contents of its mempool in a space-efficient way, which it uses to derive a bloom filter in order to query other nodes' mempools for transactions it does not have. The bloom counter's
remove_raw()
method had been panicking in #3599 because it seemed that an item was simultaneously reported as present in the bloom counter and then turned out to be absent.While this seems like a logic error (hence the original implementation's
panic!()
in this condition), it turns out this can happen naturally because an item can hash to the same bin multiple times. If the bin has value B and the item hashes to the same bin C times, where B < C, then this panic condition arises.The solution is to simply remove the panic.