max_idle_timeout config setting

[ealione]

Not necessarily a bug, but I just wanted to make sure since I'm new in Rust. On line 218, function max_transport_config, file configs.rs. the code looks like this:

let _ = config.max_idle_timeout(Some(idle_timeout)).ok();

But max_idle_timeout's documentation, when it comes to Durations, states that it should look more like this:

let _ = config.max_idle_timeout(Some(idle_timeout).try_into()?);

With the change above Pycharm does not complain anymore for mismatched_types. As I said, not a bug, just looking to discuss this with someone that knows better.

[ealione]

Another issue, in connection.rs line 462 we have the line

warn!("Error handling endpoint echo request: {}", error);

The error here should be a SendError correct?
But if that is the case, why does it not implement Display?

[ealione]

I can't create a new issue for some reason right now. But I additionally wanted to mention:

Would using serde_bytes help speed up serializing/de-serializing in cases like wire_msg?
For example in places like let mut data: Vec<u8> = vec![0; data_length];

[maqi]

Hi, @esmeraldaliaj , thank you for the effort to raise the issue and really sorry for the late reply.

when it comes to Durations, states that it should look more like this

I checked the documentation of quinn, the API of max_idle_timeout changed from taking Option<Duration> to Option<IdleTimeout> around version 7.0 or 8.0 . That explains why you seeing this mismatch error.
We will refactor the code correspondently during next round of updating dependent crates versions.
Thanks for the alert.

The error here should be a SendError correct?

Yes

But if that is the case, why does it not implement Display?

Well, it's just following the quinn stuff to implement the required stuff. The errors from quinn related to this doesn't have Display implemented either, and we don't have extra requirement for Display, so it doesn't implements Display yet.
We will implement it once we need it.

Would using serde_bytes help speed up serializing/de-serializing in cases like wire_msg?

Yes, serde_bytes has been used for some small structs already.
For the bit more complicated WireMsg, we choose to use bytes crate which provides more facility in addition to the speedy serializing/de-serializing.

Thanks again for the effort. I am currently closing the issue.
You are welcomed to raise any further comment for discussion or reopen the issue if necessary.