net-utils (& others): swap tests to non-overlapping port allocation#6957
net-utils (& others): swap tests to non-overlapping port allocation#6957puhtaytow wants to merge 27 commits intoanza-xyz:masterfrom
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #6957 +/- ##
=======================================
Coverage 83.2% 83.2%
=======================================
Files 856 856
Lines 376845 376862 +17
=======================================
+ Hits 313722 313754 +32
+ Misses 63123 63108 -15 🚀 New features to boost your workflow:
|
Thank you! 🙏 |
| let mut duplicate_slot_repair_statuses = HashMap::new(); | ||
| let dead_slot = 9; | ||
| let receive_socket = &bind_to_unspecified().unwrap(); | ||
| let receive_socket = &bind_to( |
There was a problem hiding this comment.
These code are so much repeated, maybe it is worth to create a new bind_to_unspecified utility function.
There was a problem hiding this comment.
Yes, that might be nice, but let us fix our CI first. Just changing semantics of bind_to_unspecified is not a great plan either as there are legit cases where you might want to call it.
|
I agree with Lijun that would be nice to not repeat this code everywhere. |
|
Ok, fine. @puhtaytow seems like we have to come up with a way to have a new bind_to_unspecified that works via the same mechanism as localhost_port_range_for_tests but does not allocate a full 20-port span every time. |
|
Surely. Let me look at this 🙏 |
|
Minor note but: certainly exceeds the suggested character limit for commit titles |
|
Thank you guys! 🙏 |
| assert!(start < u16::MAX - 20, "ran out of port numbers!"); | ||
| (start, start + 20) | ||
| assert!(start < u16::MAX - size, "ran out of port numbers!"); | ||
| (start, start + size) |
There was a problem hiding this comment.
do we have an off by one error here? If start is 10000, and i want 20 ports, i get back (10000, 10020) which is 21 ports.
There was a problem hiding this comment.
Very good question, i wasn't confident enough so decided to check it with the test and the code below pass positively.
let (pr_s, pr_e) = localhost_port_range_for_tests();
assert_eq!(pr_e - pr_s, 20);
...
There was a problem hiding this comment.
well ya the difference between 10020 and 10000 is 20. but if we return both of them, the user will use them all. but that is 21 ports returned even though the difference is 20.
in your example above, if i use every port from pr_e to pr_s, that is 21 ports. if we count it out: 0, 1, 2, 3, ..., 19, 20. that is 21.
There was a problem hiding this comment.
right, would you suggest to add note in the function docs or maybe return Range? instead?
There was a problem hiding this comment.
switching to range would be great, yes. Since this is a new function we might as well have proper API for it.
…han one Co-authored-by: Greg Cusack <greg.cusack@anza.xyz>
| url::Url, | ||
| }; | ||
|
|
||
| /// Helper for code that still expects port ranges as `(u16, u16)` |
There was a problem hiding this comment.
Should it be here or somewhere else?
|
The Please tell me WDYT 🙏 |
Generally it is not advised to do "drive-by" fixes for things unrelated to the subject of the PR. Not a huge deal here, but please avoid when possible. |
alexpyattaev
left a comment
There was a problem hiding this comment.
This looks like it is going in the right direction, but I feel like we should split this into 2 PRs: one to introduce new functions in net-utils, another to patch them into the codebase. Also left a few nits and bikeshedding suggestions.
| /// | ||
| /// When running without nextest, this will only bump an atomic and eventually | ||
| /// panic when it runs out of port numbers to assign. | ||
| pub fn localhost_port_single_for_tests() -> u16 { |
There was a problem hiding this comment.
Is this function redundant? If not, maybe it should be called unique_port_for_tests ?
| bind_to_async(IpAddr::V4(Ipv4Addr::LOCALHOST), 0).await | ||
| bind_to_async( | ||
| IpAddr::V4(Ipv4Addr::LOCALHOST), | ||
| localhost_port_range_for_tests().start, |
There was a problem hiding this comment.
why are we eating an entire port range for this one?
| #[test] | ||
| pub fn test_multicast_msg() { | ||
| let reader = bind_to_localhost().expect("bind"); | ||
| let reader = bind_to_localhost_unique().expect("should bind"); |
There was a problem hiding this comment.
if we are changing the messages, maybe giving them numbers would be nice?
|
Turned this PR into draft with no intentions to ever merge it. As suggested by @alexpyattaev it would be splitted into multiple PRs starting from this one #7055 Thank you and sorry for the chaos 🙏 |
Problem
A bunch of tests still relies on either hardcoded ports or bind_to_localhost and bind_to_unspecified. This creates flaky tests in cases where unique port ranges are needed.
Related to #6886
Summary of Changes
UNSPECIFIEDtoLOCALHOSTat many points.