> Finally it failed on the CI on all but one instance :-)
>
> https://github.com/haproxy/haproxy/actions/runs/14065686272/job/39387465537
>
> It's only balance-hash-maxqueue that fails, not the other one. So I'll
> mark it as "broken" with a comment saying that it tends to work locally
> but not on the CI. This way we keep the principle needed to test it and
> can even run it locally without polluting the centralized tests.
For what it is worth, `nbthread` seems to help at least on my machine: with
`nbthread 1`, I now get 100% success rate with properly serving the response
to `c1b`.
Since the issue in the CI log is that `c1b` timed out while doing `rxresp`,
this *might* actually make it work.
Either way, keeping it disabled sounds good to me as well. Thank you for
merging the patch!
diff --git a/reg-tests/balance/balance-hash-maxqueue.vtc
b/reg-tests/balance/balance-hash-maxqueue.vtc
index 7bbcaef20..e0a9ec978 100644
--- a/reg-tests/balance/balance-hash-maxqueue.vtc
+++ b/reg-tests/balance/balance-hash-maxqueue.vtc
@@ -37,9 +37,16 @@ server s1 {
barrier b_c2_is_done sync
txresp
+
+ # Respond to c1b
+ rxreq
+ txresp
} -start
haproxy h1 -arg "-L A" -conf {
+ global
+ nbthread 1
+
defaults
mode http
timeout server "${HAPROXY_TEST_TIMEOUT-5s}"
@@ -51,6 +58,7 @@ haproxy h1 -arg "-L A" -conf {
balance uri
hash-preserve-affinity maxqueue
hash-type consistent
+ http-reuse always
http-response set-header Server %s
@@ -73,6 +81,8 @@ client c1b -connect ${h1_px_sock} {
txreq -url "/test-url"
barrier b_has_txed_c1b sync
rxresp
+ expect resp.status == 200
+ expect resp.http.Server ~ s1
} -start
barrier b_has_txed_c1b sync
@@ -86,4 +96,5 @@ client c2 -connect ${h1_px_sock} {
expect resp.http.Server ~ s0
} -run
-client c1a -wait
\ No newline at end of file
+client c1a -wait
+client c1b -wait
