QUIC on Windows is less than optimally stable

[calmh]

The QUIC listener can get stuck accepting connections with the error The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress.. Apparently this can happen when we've received an ICMP error to the socket, and it doesn't appear to resolve itself. Closing the socket and reopening does resolve it.

2023-08-29T14:00:01+01:00: Listen (BEP/quic): Accepting connection: read udp [::]:22001: wsarecvmsg: The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress.
2023-08-29T14:00:09+01:00: Listen (BEP/quic): Accepting connection: read udp [::]:22001: wsarecvmsg: The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress.
2023-08-29T14:00:18+01:00: Listen (BEP/quic): Accepting connection: read udp [::]:22001: wsarecvmsg: The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress.
2023-08-29T14:00:28+01:00: Listen (BEP/quic): Accepting connection: read udp [::]:22001: wsarecvmsg: The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress.
2023-08-29T14:00:28+01:00: QUIC listener ([::]:22001) shutting down
2023-08-29T14:00:28+01:00: listenerSupervisor@quic://0.0.0.0:22001: service quic://0.0.0.0:22001 failed: read udp [::]:22001: wsarecvmsg: The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress.
2023-08-29T14:00:28+01:00: QUIC listener ([::]:22001) starting
2023-08-29T14:00:28+01:00: Established secure connection to APT5NA5 at [::]:22001-10.95.3.29:22001/quic-server/TLS1.3-TLS_AES_128_GCM_SHA256/WAN-P40-2TVTO8P5AP2O1KI4I40T7FRDGK
2023-08-29T14:00:29+01:00: Established secure connection to 5SJ3GHH at [::]:22001-10.90.3.29:22001/quic-server/TLS1.3-TLS_AES_128_GCM_SHA256/WAN-P40-2TVTO8RAG3CHG09DU7BF0CH3H8
2023-08-29T14:00:29+01:00: Established secure connection to X3JCY2I at [::]:22001-10.96.3.129:22001/quic-server/TLS1.3-TLS_AES_128_GCM_SHA256/WAN-P40-2TVTO8RF2RUCHL7TL97Q8F537C

We do actually try to resolve this by shutting down the listener and re-opening the socket when several accept calls fail in a row. However, it's likely to happen again on a box talking to several devices over QUIC, as soon as any of them become unreachable and we get an ICMP error it cancels all the connections, since all connections share an underlying UDP socket...

[bt90]

Isn't this something that quic-go should handle?

[calmh]

Maybe? Or maybe Go itself? If it's possible, I don't know.

[bt90]

Maybe quic-go/quic-go#1737 ?

[calmh]

Maybe.

[bt90]

Can you reproduce it or is this a once-in-a-blue-moon scenario?