tls-rustls-reload example not reloading periodically

[mixaal]

Describe the bug

the tls-rustls-reload loads the certificates just once at the startup, it never re-attempts to go thru the loop inside the async stream again.

To Reproduce

This little code change makes it more clear, set the reloading duration to 1sec and put some debug messages around. The messages are seen only once as the sleep await is never woke up.

diff --git a/examples/tls-rustls-reload/src/main.rs b/examples/tls-rustls-reload/src/main.rs
index e7fe77bc..deda2a30 100644
--- a/examples/tls-rustls-reload/src/main.rs
+++ b/examples/tls-rustls-reload/src/main.rs
@@ -15,8 +15,10 @@ async fn main() {
     let acceptor = TcpListener::new("0.0.0.0:5800")
         .rustls(async_stream::stream! {
             loop {
+                tracing::info!("loading config...");
                 yield load_config();
-                tokio::time::sleep(Duration::from_secs(60)).await;
+                tracing::info!("sleeping...");
+                tokio::time::sleep(Duration::from_secs(1)).await;
             }
         })
         .bind()

Expected behavior
I assume we want to see messages to appear every 1s tick.

Screenshots

Desktop (please complete the following information):

OS: Ubuntu 23.10

uname -a
Linux smurf 6.5.0-35-generic #35-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 26 11:23:57 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

rustc version:

rustc --version
rustc 1.76.0 (07dca489a 2024-02-04)

[mixaal]

Apparently the tls is reloaded when the server is in use, e.g. by issuing curl on the / endpoint. So maybe it's expected behavior but might be noted in the doc.

[markcda]

I believe that the stream created is not awaiting without use. To achieve the result you want, it is necessary to create a separate background task that will constantly work and be expected by someone. You can come up with a solution using tokio::sync::mpsc, when a stream for rustls(...) expects an answer from the channel, and the background task throws the data into the channel (the main thing is to constantly read the channel to avoid its overflow); Arc<Mutex<...>> is also acceptable. In essence, you can make a timer in Arc<Mutex<...>>, which will allow you to determine whether a certain time has passed, and then re-read the configuration and yield, or continue to wait for the timer.