From: Amaury Denoyelle <adenoyelle@haproxy.com>
Date: Tue, 8 Jul 2025 08:30:46 +0000 (+0200)
Subject: BUG/MINOR mux-quic: apply correctly timeout on output pending data
X-Git-Tag: v3.3-dev4~48
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c5bcc3a21ef371b81099cc0c6a4a27ae34d7726b;p=thirdparty%2Fhaproxy.git

BUG/MINOR mux-quic: apply correctly timeout on output pending data

When no stream is attached, mux layer is responsible to maintain a
timeout. The first criteria is to apply client/server timeout if there
is still data waiting for emission.

Previously, <hreq> qcc member was used to determine this state. However,
this only covers bidirectional streams. Fix this by testing if
<send_list> is empty or not. This is enough to take into account both
bidi and uni streams.

Theorically, this should be backported to every stable versions.
However, send-list is not available on 2.6 and there is no alternative
to quickly determine if there is waiting output data. Thus, it's better
to backport it up to 2.8 only.
---

diff --git a/src/mux_quic.c b/src/mux_quic.c
index c24c8b09a..5f10c23ab 100644
--- a/src/mux_quic.c
+++ b/src/mux_quic.c
@@ -325,8 +325,8 @@ static void qcc_refresh_timeout(struct qcc *qcc)
 	 * processed if shutdown already one or connection is idle.
 	 */
 	if (!conn_is_back(qcc->conn)) {
-		if (qcc->nb_hreq && qcc->app_st < QCC_APP_ST_SHUT) {
-			TRACE_DEVEL("one or more requests still in progress", QMUX_EV_QCC_WAKE, qcc->conn);
+		if (!LIST_ISEMPTY(&qcc->send_list) || !LIST_ISEMPTY(&qcc->tx.frms)) {
+			TRACE_DEVEL("pending output data", QMUX_EV_QCC_WAKE, qcc->conn);
 			qcc->task->expire = tick_add_ifset(now_ms, qcc->timeout);
 			task_queue(qcc->task);
 			goto leave;