Willy Tarreau 03e9a5a1e7 BUG/MAJOR: lb-chash: fix key calculation when using default hash-key id ... A subtle regression was introduced in 3.0 by commit faa8c3e02 ("MEDIUM: lb-chash: Deterministic node hashes based on server address"). When keys are calculated from the server's ID (which is the default), due to the reorganisation of the code, the key ended up being hashed twice instead of being multiplied by the scaling range. While most users will never notice it, it is blocking some large cache users from upgrading from 2.8 to 3.0 or 3.2 because the keys are redistributed. After a check with users on the mailing list [1] it was estimated that keep the current situation is the worst choice because those who have not yet upgraded will face the problem while by fixing it, those who already have and for whom it happened smoothly will handle it just right again. As such this fix must be backported to 3.0 without waiting (in order to preserve those who upgrade from two redistributions). Please note that only configurations featuring "hash-type consistent" and not having "hash-key" present with a value other than "id" are affected, others are not (e.g. "hash-key addr" is unaffected). [1] https://www.mail-archive.com/haproxy@formilux.org/msg46115.html		2025-10-16 10:43:09 +02:00
..
balance-hash-maxconn.vtc	BUG/MAJOR: lb-chash: fix key calculation when using default hash-key id	2025-10-16 10:43:09 +02:00
balance-hash-maxqueue.vtc	REGTESTS: restrict execution to a single thread group	2025-06-30 18:54:35 +02:00
balance-rr.vtc	REGTESTS: restrict execution to a single thread group	2025-06-30 18:54:35 +02:00
balance-uri-path-only.vtc	REGTESTS: restrict execution to a single thread group	2025-06-30 18:54:35 +02:00
balance-uri.vtc	REGTESTS: restrict execution to a single thread group	2025-06-30 18:54:35 +02:00