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