Problem
TcpOpts (crates/turnloop/src/types.rs) has exactly one field:
pub struct TcpOpts {
pub nodelay: bool,
}Every other pre-connect TCP option a caller might want — a connect timeout, a local bind address, keepalive parameters set at connect time, IPV6_V6ONLY, and so on — has no field to set.
Why it matters
This is P1's and P6's item, unchanged, and Perry's P11 lane (perry-http-client, the perry CLI's HTTP client) hit it again: its report lists it as still open, verbatim "TcpOpts still exposes only nodelay."
Note this is a different gap from turnloop#34 ("No socket options after creation"), which is now closed (implemented in #36, merged 909e92f) and added Loop::set_option/get_option for options changed after a handle exists. TcpOpts is the struct passed at connect time, and it is unaffected by that fix — checked against current main (d0f0167), it still only has nodelay.
What would fix it
Either extend TcpOpts with the connect-time fields callers actually need (a connect timeout is the one every HTTP client reaches for first), or — if the intent is that everything now goes through Loop::set_option/get_option post-creation — say so explicitly in TcpOpts's docs and point callers at the post-creation API, so a caller doesn't have to guess whether the single field is an oversight or a deliberate boundary.
Problem
TcpOpts(crates/turnloop/src/types.rs) has exactly one field:Every other pre-connect TCP option a caller might want — a connect timeout, a local bind address, keepalive parameters set at connect time,
IPV6_V6ONLY, and so on — has no field to set.Why it matters
This is P1's and P6's item, unchanged, and Perry's P11 lane (
perry-http-client, theperryCLI's HTTP client) hit it again: its report lists it as still open, verbatim "TcpOptsstill exposes onlynodelay."Note this is a different gap from turnloop#34 ("No socket options after creation"), which is now closed (implemented in #36, merged
909e92f) and addedLoop::set_option/get_optionfor options changed after a handle exists.TcpOptsis the struct passed at connect time, and it is unaffected by that fix — checked against currentmain(d0f0167), it still only hasnodelay.What would fix it
Either extend
TcpOptswith the connect-time fields callers actually need (a connect timeout is the one every HTTP client reaches for first), or — if the intent is that everything now goes throughLoop::set_option/get_optionpost-creation — say so explicitly inTcpOpts's docs and point callers at the post-creation API, so a caller doesn't have to guess whether the single field is an oversight or a deliberate boundary.