-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
.with_idle_connection_timeout(Duration::from_secs(u64::MAX))
still a bug.
#4641
Comments
.with_idle_connection_timeout(Duration::from_secs(u64::MAX)
still a bug..with_idle_connection_timeout(Duration::from_secs(u64::MAX))
still a bug.
Which rust-libp2p commit off of |
It's d6351ee. I did try clean and delete Cargo.lock to fetch newest but still the same result. |
Thank you for the quick response. The panic seems to be here: rust-libp2p/swarm/src/connection.rs Lines 351 to 361 in 74c087d
Similar to what #4559 fixed, we need the same fix in
@zrus would you mind proposing a patch in a new pull request using @thomaseizinger long term, I don't think representing the never timeout state with |
Sure. |
That doesn't solve the panics though right? We still need to properly deal with all cases where users give us a very long duration. What we could do is move away from |
I am fine with either:
|
Summary
Simply set idle timeout connection for swarm to
Duration::from_secs(u64)
orDuration::MAX
still causeoverflow when adding duration to instant
.Expected behavior
As the examples, I want to keep connections forever.
Actual behavior
thread 'tokio-runtime-worker' panicked at library/std/src/time.rs:419:33: overflow when adding duration to instant
Relevant log output
Possible Solution
No response
Version
Directly from github on branch
master
Would you like to work on fixing this bug ?
No
The text was updated successfully, but these errors were encountered: