refactor: [#682] handle UDP Tracker timeouts

[hungfnt]

I don't know how to simulate the timeout yet.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 0% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 78.61%. Comparing base (3c78bba) to head (2a8a15d).

Files	Patch %	Lines
src/shared/bit_torrent/tracker/udp/client.rs	0.00%	4 Missing :warning:

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #827      +/-   ##
===========================================
- Coverage    78.83%   78.61%   -0.23%     
===========================================
  Files          169      169              
  Lines         9341     9225     -116     
===========================================
- Hits          7364     7252     -112     
+ Misses        1977     1973       -4     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[josecelano]

I don't know how to simulate the timeout yet.

Hi @ngthhu, for receiving data from the socket:

let size_result = match time::timeout(self.timeout, self.socket.recv(bytes)).await {
    Ok(recv_result) => match recv_result {
        Ok(size) => Ok(size),
        Err(e) => Err(anyhow!("IO error during send: {e:?}")),
    },
    Err(_) => bail!(ClientError::ConnectionTimeout),
};

You can manually test just by running the tracker with a delay (thread sleep) in the handler.

For other timeouts, like waiting for the socket to be writable, I do not have any idea either. I would probably try to write unit tests mocking the UdpSocket. I'm writting articles about testing in Rust.

The problem is testing time-related stuff is hard and slow. We could research how to do it properly. I don't like having tests that have to "wait" to test functionality, even if we set a short timeout for testing.

[josecelano]

Hi @ngthhu, @da2ce7 was also working on adding timeouts to the UDP client.

Regarding how to test this code. I have not thought about it yet but I have the impression that we will need:

• To mock the time and timeout.
• Be able to set each timeout with different values. SO we can assign high values for the ones we don't want to test and a low value for the timeout we want to capture.

I've also found this post about this topic:

https://ditto.live/blog/mocking-time-in-async-rust

[da2ce7]

closed as stale.