I did this
Component
libcurl → HTTP/3 ngtcp2/nghttp3 backend (lib/vquic/curl_ngtcp2.c)
What happens
When ngtcp2_conn_writev_stream() returns NGTCP2_ERR_STREAM_DATA_BLOCKED for a given stream_id, the code marks quic_flow_blocked on the transfer associated with x->data (the “current” easy handle) instead of the transfer that actually owns stream_id. In multiplexed HTTP/3, this mislabels the state: the truly blocked stream is left unmarked while an unrelated stream is flagged as flow-blocked. This can cause the wrong request to be paused/woken and the actually blocked stream to stall until unrelated activity nudges scheduling again.
Why this is wrong
NGTCP2_ERR_STREAM_DATA_BLOCKED is a per-stream condition (flow control on that specific stream_id). Handling it must update the state for that exact stream, not whatever x->data happens to point to at the moment.
I expected the following
No response
curl/libcurl version
current version
operating system
all of them
I did this
Component
libcurl → HTTP/3 ngtcp2/nghttp3 backend (lib/vquic/curl_ngtcp2.c)
What happens
When ngtcp2_conn_writev_stream() returns NGTCP2_ERR_STREAM_DATA_BLOCKED for a given stream_id, the code marks quic_flow_blocked on the transfer associated with x->data (the “current” easy handle) instead of the transfer that actually owns stream_id. In multiplexed HTTP/3, this mislabels the state: the truly blocked stream is left unmarked while an unrelated stream is flagged as flow-blocked. This can cause the wrong request to be paused/woken and the actually blocked stream to stall until unrelated activity nudges scheduling again.
Why this is wrong
NGTCP2_ERR_STREAM_DATA_BLOCKED is a per-stream condition (flow control on that specific stream_id). Handling it must update the state for that exact stream, not whatever x->data happens to point to at the moment.
I expected the following
No response
curl/libcurl version
current version
operating system
all of them