On Tue, Jul 29, 2025 at 04:10:12PM +0300, Luke Seelenbinder wrote: > Hi list, > We're working on debugging a quic/h3 issue on 3.2.3. > The client shows a QUIC error (on Chrome v138). The server shows CD--, and > the connections timeout. The client then retries after ~6s on http2, and > everything succeeds. > We're seeing the following debug details on the connections: > fs=< qcs=0x7ff797f4ca00 .id=176 .st=HCR .flg=0x0181 .rx=486/1474200 rxb=0(1) > .tx=0 0/6291456 buf=0(0)/0 .ti=30148/29785/0 qcc=0x7ff798552200(F) > qc=0x7ff797fe0000 .st=INIT .sc=11 .hreq=11 .flg=0x0028 .tx=8133047 > 8133047/15728640 bwnd=492506/491520 conn.flg=0x803c0300 qc.wnd=511307/491520> > bs=< h1s=0x7ff7954c7fc0 h1s.flg=0x14094 .req.state=MSG_DONE > .res.state=MSG_DATA .meth=GET status=200 .sd.flg=0x106c0a01 .sd.evts=E1 > .sc.flg=0x00035211 .sc.app=0x7ff797857c00 .sc.evts=S1 .subs=(nil) > h1c.flg=0x80004800 .sub=0 .ibuf=15568@0x7ff78cf96500+800/16384 > .obuf=0@(nil)+0/0 .evts=M1 .task=0x7ff79251eec0 .exp=<NEVER> > conn.flg=0x080300 conn.err_code=0 conn.evts=F1>
At first glance, I'm seeing value 0x0181 for QCS instances, which can be translated as QC_SF_HREQ_RECV | QC_SF_TO_RESET | QC_SF_SIZE_KNOWN. The second flag is probably the issue here : the stream has been resetted by haproxy. This can occur due to several reasons : * a STOP_SENDING frame was received * an error during HTTP/3 decoding * stream is shut prematurely by its upper haproxy layer To further investigate on the issue, the easiest solution would be to activate traces, so that we can detect which one of the condition above was encountered. The simplest way is to use the following command-line argument to haproxy : '-dt qmux:developer:minimal', to output debug traces on stderr. This will be really verbose, if not suitable a traces section can be configured to redirect output on a sink. Regards, -- Amaury Denoyelle
