Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(tx-fetcher): only remove peer from active_peers when inflight_count <= 0 #6928

Merged
merged 3 commits into from Mar 3, 2024

Conversation

int88
Copy link
Contributor

@int88 int88 commented Mar 2, 2024

fix logic error of decrement_inflight_request_count_for.

Signed-off-by: int88 <golden-miner@qq.com>
@mattsse mattsse added C-bug An unexpected or incorrect behavior A-networking Related to networking in general labels Mar 2, 2024
Copy link
Member

@emhane emhane left a comment

Choose a reason for hiding this comment

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

nice find! this hasn't been a problem now, since DEFAULT_MAX_COUNT_CONCURRENT_REQUESTS_PER_PEER is 1. hence when a request resolves, the peer should indeed always be removed from active peers. but, the code isn't future proof for when we make the max count configurable.

please when you find a bug like this, add a test in the pr that fixes it to cover the buggy code.

thanks!

@@ -90,10 +90,10 @@ impl TransactionFetcher {
fn decrement_inflight_request_count_for(&mut self, peer_id: &PeerId) {
let remove = || -> bool {
if let Some(inflight_count) = self.active_peers.get(peer_id) {
if *inflight_count <= DEFAULT_MAX_COUNT_CONCURRENT_REQUESTS_PER_PEER {
*inflight_count -= 1;
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
*inflight_count -= 1;
*inflight_count.saturating_sub(1);

better safe than sorry

Copy link
Member

Choose a reason for hiding this comment

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

i'm a proponent of using checked methods in case of unintended behavior such as this, thoughts?

@int88
Copy link
Contributor Author

int88 commented Mar 2, 2024

please when you find a bug like this, add a test in the pr that fixes it to cover the buggy code.

will do :)

@int88
Copy link
Contributor Author

int88 commented Mar 3, 2024

@emhane updated :)

Copy link
Member

@emhane emhane left a comment

Choose a reason for hiding this comment

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

lgtm

@emhane emhane added this pull request to the merge queue Mar 3, 2024
Merged via the queue into paradigmxyz:main with commit b758620 Mar 3, 2024
29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-networking Related to networking in general C-bug An unexpected or incorrect behavior
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants