From: Willy Tarreau Date: Tue, 22 Sep 2026 21:53:49 +0000 (+0000) Subject: REGTESTS: http-messaging: widen the abort window of the abortonclose test X-Git-Tag: v3.5-dev8~10 X-Git-Url: https://git.kaiwu.me/?a=commitdiff_plain;h=e81f01771b02802ac31614d3f949523404ff5f01;p=haproxy.git REGTESTS: http-messaging: widen the abort window of the abortonclose test Running the whole suite with "--j 32" caught the /c5 request being answered with the 503 of the exhausted connection retries and logged "SC--" where the test expects the "CC--" of a client abort. That request is sent by a client which closes immediately, and the abort has to be noticed before the retries are over, which the connect timeout of a hundred milliseconds does not guarantee on a process starved by thirty-two parallel tests: the log of the failing run shows the whole retry sequence completed in exactly those 100 ms. The connect timeout of the section that request uses is raised to one second, which leaves ten times more room and does not make the test any slower, since the expected outcome is precisely that the abort cuts the retries short. The other section, whose request is expected to wait for all the retries, is left untouched. --- diff --git a/reg-tests/http-messaging/http_abortonclose.vtc b/reg-tests/http-messaging/http_abortonclose.vtc index 33b194dff..c5eb1d37c 100644 --- a/reg-tests/http-messaging/http_abortonclose.vtc +++ b/reg-tests/http-messaging/http_abortonclose.vtc @@ -68,6 +68,7 @@ haproxy h1 -conf { .if feature(THREAD) thread-groups 1 .endif + chroot / # WT: limit false-positives causing "HTTP header incomplete" due to # idle server connections being randomly used and randomly expiring @@ -118,19 +119,26 @@ haproxy h2 -conf { .if feature(THREAD) thread-groups 1 .endif + chroot / # WT: limit false-positives causing "HTTP header incomplete" due to # idle server connections being randomly used and randomly expiring # under us. tune.idle-pool.shared off + # The client of the /c5 request below aborts while the connection to + # the server is being retried, and the abort has to be noticed + # before the retries are over. A hundred milliseconds is not much + # for a process which is starved by a parallel run of the whole + # suite, where this was seen reporting the 503 of the exhausted + # retries instead, so the connect timeout is one second here. defaults mode http no option abortonclose retries 1 timeout client 10s timeout server 10s - timeout connect 100ms + timeout connect 1s timeout queue 5s frontend fe1