On Wed, Sep 23, 2026 at 11:43:34AM +0200, Amaury Denoyelle wrote: > On Wed, Sep 23, 2026 at 06:20:18PM +0900, ygkat wrote: > [...] > > Wanted to check first in case you see any problem with us applying > > both of these internally ahead of whatever ends up merged upstream, or > > any risk specific to a frontend-only QUIC deployment that we might be > > missing beyond the backend point you already raised. > I think the patch on qcc_recv_reset_stream() is safe so I encourage you > to run with it. The reorder change in qcc_is_dead() is definitely larger > and could trigger truncated streams on QUIC frontend side. If you decide > to use it, it would be a good idea to check that the number of stream > errors is not increased. > I'll notify you when the final patches will be merged on our side.
Okay so I have finally merge two patches which should fix the connection leak. * BUG/MAJOR: mux_quic: fix leak on RESET_STREAM reception This addresses the main issue and is sufficient to fix both the QCS and the connection leaks. This ensures that a stream is freed as soon as possible when a RESET_STREAM is received and upper layer is not yet present. This has the side-effect of decrementing <nb_hreq>, so the connection is not blocked anymore on idle timeout. * BUG/MEDIUM: mux_quic: activate timeout on FE init This one has a broader scope. Its objective is to ensure the timeout is activated as soon as possible when MUX layer is initialized. It should act as a final measure to ensure a connection is released if receiving only non-STREAM frames, even if there are already other refresh mechanisms in the various frame handlers. Regarding the issue you encountered, this is not strictly necessary but I consider this a good protection against any possible non anticipated cases. I encourage you to pick both patches and check if the connection leak is resolved. Additionnaly, they are already merged on top of 3.2 dev branch (a new release should come soon). Regarding the discussed change about qcc_is_dead(), I consider it as not compatible with the approach of the muxes in haproxy and it may cause truncated requests in some cases so I won't picked it. Many thanks for your help to resolve this issue. Do not hesitate to share with us if you have other issues or thoughts/ideas on QUIC in haproxy as it is always good to have testers and reporters, Regards, -- Amaury Denoyelle
