You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But I also tried after calling cargo update, so anything latest of time of this posting is also affected.
Platform
Linux hostname 6.6.47 #1-NixOS SMP PREEMPT_DYNAMIC Mon Aug 19 04:04:32 UTC 2024 x86_64 GNU/Linux
Description
I tried to create a small project to reproduce this, but it's too involved, I think tonic and an unavailable gRPC endpoint might be involved.
This is a summary:
I am running cargo test with a #[tokio::test] test
I am calling a tokio::time::timeout on a method that has the following relevant contents:
tries to connect to a tonic gRPC endpoint (presumably failing to) and unwraps the result
before, we used to check for .is_err() on this result and retrying, and that worked, so it's this unwrap inside the tokio::timeout that is actually causing the hang
supposedly tokio::time::sleeps after failure
It seems to me that maybe the tonic connect attempt hangs for a long time and tokio's timeout is not cutting that short.
Reproduce
In my own project, you can reproduce as follows, sorry it's pretty annoying:
install bitcoind (bitcoin-core), sorry it's a dep and it's a bit annoying to remove it (package managers have it nowadays)
I can't help you without a smaller example. The timeout function definitely doesn't ignore or hang on panic. Something else must be going on. This issue doesn't sound like a Tokio bug from what you have described so far.
Version
List the versions of all
tokio
crates you are using. The easiest way to getthis information is using
cargo tree
subcommand:But I also tried after calling
cargo update
, so anything latest of time of this posting is also affected.Platform
Description
I tried to create a small project to reproduce this, but it's too involved, I think tonic and an unavailable gRPC endpoint might be involved.
This is a summary:
cargo test
with a#[tokio::test]
testtokio::time::timeout
on a method that has the following relevant contents:.is_err()
on this result and retrying, and that worked, so it's this unwrap inside thetokio::timeout
that is actually causing the hangtokio::time::sleep
s after failureIt seems to me that maybe the tonic connect attempt hangs for a long time and tokio's timeout is not cutting that short.
Reproduce
In my own project, you can reproduce as follows, sorry it's pretty annoying:
https://codeberg.org/ark-bitcoin/bark.git
tokio-hang
or commitb94a71be3a70e167bfd38a258322e29141666814
just test-integration fund_
or do the following:cargo build --workspace
$(pwd)/target/debug/aspd
cargo test -p ark-testing fund_
The text was updated successfully, but these errors were encountered: