-
Notifications
You must be signed in to change notification settings - Fork 43
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
ping/rust: adapt to rust-sdk patch, remove unused dependencies #42
Conversation
See release of v0.48.0 in libp2p/rust-libp2p#2869. Master bump to v0.49.0 in libp2p/rust-libp2p#2813
ping/rust/src/main.rs
Outdated
@@ -85,7 +88,7 @@ async fn main() -> Result<(), Box<dyn std::error::Error>> { | |||
} | |||
|
|||
let mut address_stream = client | |||
.subscribe("peers") | |||
.subscribe("peers", 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we set a higher capacity here? I am not familiar with how the background task works but the description in testground/sdk-rust#36 indicates that there is a footgun related to this. Concretely I am not sure if its an issue that we first create the stream, then publish our own message (and maybe it's blocking here?) before we start polling the stream.
CI is failing currently, and this is the only change that I can think of that is causing this.
On the other hand, before this patch we were using an older version of the rust-sdk were also capacity 1 was used: https://github.com/testground/sdk-rust/blob/b6aa70a32cdb31d27ee14a73b9e6fd325cf5fe1f/src/client.rs#L110.
Alternatively, could we just publish our own message before subscribing?
CC @mxinden since you were the author of testground/sdk-rust#36.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@elenaf9 Sorry for the typo in the README and thanks a lot for beta-testing and fixing the workflow 🙏
Regarding the failure, just a note in case that helps: CI is failing because the run is reaching the 6 minutes timeout.
https://github.com/libp2p/test-plans/actions/runs/3076811088/jobs/4971230622 (from my experience it takes between 1 and 2 minutes).
I can't tell where in the loop that happens, we'd need more logs, but it looks like there's a 10s hang between some iterations:
Sep 18 10:53:21.455380 INFO 211.7877s ERROR << 0.48.0[000] (760771) >> [2022-09-18T10:53:21Z INFO testplan] Event: Behaviour(Event { peer: PeerId("12D3KooWF1r3xcd5BiaLoCZjcfknWBnZE9gCyzd8mSuSRSiyGaJJ"), result: Ok(Pong) })
Sep 18 10:53:21.455461 INFO 211.7878s ERROR << v0.44.0[000] (3ad09f) >> [2022-09-18T10:53:21Z INFO testplan] Event: Behaviour(Event { peer: PeerId("12D3KooWNndM73hpCtFFYHwerYsAYYoAe7iqW2vcnUVHimmjL7PE"), result: Ok(Ping { rtt: 601.899µs }) })
# note the time jumping from 211 seconds to 221 seconds.
Sep 18 10:53:31.436076 INFO 221.7684s ERROR << v0.45.1[000] (a2d41f) >> [2022-09-18T10:53:31Z INFO testplan] Event: Behaviour(Event { peer: PeerId("12D3KooWF1r3xcd5BiaLoCZjcfknWBnZE9gCyzd8mSuSRSiyGaJJ"), result: Ok(Pong) })
Sep 18 10:53:31.436141 INFO 221.7685s ERROR << v0.45.1[000] (a2d41f) >> [2022-09-18T10:53:31Z INFO testplan] Event: Behaviour(Event { peer: PeerId("12D3KooWF1r3xcd5BiaLoCZjcfknWBnZE9gCyzd8mSuSRSiyGaJJ"), result: Ok(Ping { rtt: 516.899µs }) })
Sep 18 10:53:31.436172 INFO 221.7685s ERROR << v0.46.0[000] (155fcf) >> [2022-09-18T10:53:31Z INFO testplan] Event: Behaviour(Event { peer: PeerId("12D3KooWNndM73hpCtFFYHwerYsAYYoAe7iqW2vcnUVHimmjL7PE"), result: Ok(Pong) })
...
Sep 18 10:53:31.455713 INFO 221.7880s ERROR << v0.46.0[000] (155fcf) >> [2022-09-18T10:53:31Z INFO testplan] Event: Behaviour(Event { peer: PeerId("12D3KooWDbRZhiWMUKmhLY7e7jPkvyf9eECmFCUvzjMN3cGszRuU"), result: Ok(Ping { rtt: 262.2µs }) })
Sep 18 10:53:31.455726 INFO 221.7880s ERROR << v0.44.0[000] (3ad09f) >> [2022-09-18T10:53:31Z INFO testplan] Event: Behaviour(Event { peer: PeerId("12D3KooWNndM73hpCtFFYHwerYsAYYoAe7iqW2vcnUVHimmjL7PE"), result: Ok(Ping { rtt: 311.099µs }) })
# again
Sep 18 10:53:41.436572 INFO 231.7689s ERROR << v0.46.0[000] (155fcf) >> [2022-09-18T10:53:41Z INFO testplan] Event: Behaviour(Event { peer: PeerId("12D3KooWNndM73hpCtFFYHwerYsAYYoAe7iqW2vcnUVHimmjL7PE"), result: Ok(Pong) })
Sep 18 10:53:41.436588 INFO 231.7689s ERROR << v0.45.1[000] (a2d41f) >> [2022-09-18T10:53:41Z INFO testplan] Event: Behaviour(Event { peer: PeerId("12D3KooWF1r3xcd5BiaLoCZjcfknWBnZE9gCyzd8mSuSRSiyGaJJ"), result: Ok(Pong) })
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.subscribe("peers", 1) | |
.subscribe("peers", client.run_parameters().test_instance_count as usize) |
I suggest setting it to the amount of messages we expect to receive on the channel.
Alternatively, could we just publish our own message before subscribing?
I think we could do that. In other words I think the sync service allows us to still retrieve all the addresses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did both changes because imo they each make sense independently of the other.
Edit: It seems like the sync service does not allow publishing a message before subscribing. Thus I left the existing order and just cahnged the channel capacity like you suggested it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ping/rust/src/main.rs
Outdated
@@ -85,7 +88,7 @@ async fn main() -> Result<(), Box<dyn std::error::Error>> { | |||
} | |||
|
|||
let mut address_stream = client | |||
.subscribe("peers") | |||
.subscribe("peers", 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.subscribe("peers", 1) | |
.subscribe("peers", client.run_parameters().test_instance_count as usize) |
I suggest setting it to the amount of messages we expect to receive on the channel.
Alternatively, could we just publish our own message before subscribing?
I think we could do that. In other words I think the sync service allows us to still retrieve all the addresses.
Any idea why the CI is still failing @mxinden @laurentsenta? |
@elenaf9 have you had a chance to run the tests locally?
It looks like the test hangs for ~6 minutes. I haven't had time to debug this yet, but I get a similar timeout on my machine. |
ping/rust/Cargo.toml
Outdated
serde_json = "1" | ||
soketto = "0.7.1" | ||
testground = {git = "https://github.com/testground/sdk-rust", rev = "94a9a72796f94cc7ca786a5f019d07f328c76d4b", version = "0.4.0"} | ||
testground = {git = "https://github.com/testground/sdk-rust", branch = "master", version = "0.4.0"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we pin this?
If tomorrow, rust-sdk
publish a new version this will break the build for every interop test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I released v0.4.0
yesterday. I suggest we use the released version instead.
https://github.com/testground/sdk-rust/releases/tag/v0.4.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I released
v0.4.0
yesterday. I suggest we use the released version instead.
Of course you are maintaining that too 😂
If I am not mistaken, none of the nodes are able to connect to the node based on |
I suspect libp2p/rust-libp2p#2954 will fix the failures here. |
With libp2p/rust-libp2p#2954 merged, this should go green now. Triggering CI. |
@elenaf9 can you merge latest |
🎉 CI is green. Thanks for the help @mxinden! |
cargo update
.--from
the testground CLI did not accept the current instruction described in the README. Does it work for other folks / did I do something wrong?Builds on #41.