SYSTEM Cited by 1 source

tokio-rustls

tokio-rustls is the async adapter bolted onto rustls so TLS streams fit into Tokio's AsyncRead/AsyncWrite contract. GitHub. Unlike the wrappers most Rust proxies layer on top of their own I/O types, tokio-rustls has to "get intimate with the underlying async executor" (Source: sources/2025-02-26-flyio-taming-a-voracious-rust-proxy) — it drives Wakers on buffered reads, TLS state changes, and handshake completion, which makes it exactly the layer where waker-mis-handling bugs manifest.

This is where the 2025-02 Fly.io incident's infinite-loop bug lived (before being fixed upstream in rustls itself, PR #1950).

Seen in

• sources/2025-02-26-flyio-taming-a-voracious-rust-proxy — incident epicentre. The flamegraph's fully-qualified Future type had tokio_rustls::server::TlsStream<…> sandwiched between Fly.io's own wrapper types. On orderly TLS shutdown with buffered data still on the socket, the TlsStream's Waker handling would fire spuriously and the containing Duplex Future would be poll'd in a tight loop ("samples that almost terminate in libc, but spend next to no time in the kernel doing actual I/O"). Tracked in tokio-rustls#72; fix landed upstream at the rustls layer.

Related

• systems/rustls — the underlying TLS implementation.
• systems/tokio — the runtime tokio-rustls integrates with.
• systems/fly-proxy — downstream consumer via Fly's fly-proxy wrapper stack.
• asyncread-contract — the poll_read contract TlsStream has to satisfy.
• tls-close-notify — the TLS-protocol event that exposes the buffered-trailer edge case.
• spurious-wakeup-busy-loop — the failure mode.
• patterns/upstream-the-fix — the resolution shape.
• companies/flyio