Stats average counters high after upgrade to 3.4.1

No file pointers are given, so start with a minimal reproducer: a single backend with an average-response-time counter, one burst of slow responses, then quiet traffic, run on 3.2.19 and 3.4.1 side by side. Read how the stats module computes and decays the rtime counter (the 1024-request window) and review what changed in those counters between the two releases. Done means the counter drops back in step with the logged p50/p95 within the same window on 3.4.1, and the differing behaviour is explained.

Detailed Description of the Problem

After upgrading from 3.2.19 to 3.4.1 I have some stats counters exhibit weird behavior, they look like they remain high for an extended period of time after spiking.

Here is an image of one of the rtime (average response time over 1024 requests) backend server graphs:

At the same time, here is data from the logs - count of requests, 50th, 95th, 99th and max response time for each minute for this backend server.

┌──────────────minute─┬─cnt─┬─p50_srv_response─┬─p95_srv_response─┬─p99_srv_response─┬─max_srv_response─┐
 1. │ 2026-06-29 15:55:00 │ 194 │                1 │              109 │              198 │              488 │
 2. │ 2026-06-29 15:56:00 │ 745 │                1 │              111 │              208 │              526 │
 3. │ 2026-06-29 15:57:00 │ 792 │                1 │               95 │              249 │            10133 │
 4. │ 2026-06-29 15:58:00 │ 771 │                1 │             8491 │            17261 │            19702 │
 5. │ 2026-06-29 15:59:00 │ 658 │                0 │              131 │              323 │             3687 │
 6. │ 2026-06-29 16:00:00 │ 661 │                0 │               91 │              172 │              468 │
 7. │ 2026-06-29 16:01:00 │ 660 │                0 │               89 │              239 │              884 │
 8. │ 2026-06-29 16:02:00 │ 692 │                0 │               94 │              259 │            11892 │
 9. │ 2026-06-29 16:03:00 │ 646 │                0 │               93 │              226 │             1198 │
10. │ 2026-06-29 16:04:00 │ 667 │                0 │              132 │              313 │              647 │
11. │ 2026-06-29 16:05:00 │ 617 │                0 │              109 │              361 │             1178 │
12. │ 2026-06-29 16:06:00 │ 694 │                0 │              113 │              184 │              402 │
13. │ 2026-06-29 16:07:00 │ 734 │                0 │               97 │              195 │              538 │
14. │ 2026-06-29 16:08:00 │ 930 │                1 │               86 │              165 │              496 │
15. │ 2026-06-29 16:09:00 │ 679 │                0 │               87 │              173 │              338 │
16. │ 2026-06-29 16:10:00 │ 754 │                0 │              123 │              195 │              910 │
17. │ 2026-06-29 16:11:00 │ 700 │                0 │              101 │              171 │              624 │
18. │ 2026-06-29 16:12:00 │ 754 │                0 │              130 │              257 │              781 │
19. │ 2026-06-29 16:13:00 │ 726 │                0 │               88 │              247 │             3510 │
20. │ 2026-06-29 16:14:00 │ 779 │                0 │              123 │              208 │              549 │
21. │ 2026-06-29 16:15:00 │ 752 │                0 │              101 │              179 │              499 │
22. │ 2026-06-29 16:16:00 │ 753 │                0 │              125 │              181 │              958 │
23. │ 2026-06-29 16:17:00 │ 725 │                0 │              131 │              410 │              955 │
24. │ 2026-06-29 16:18:00 │ 550 │                0 │               87 │              169 │              259 │
    └─────────────────────┴─────┴──────────────────┴──────────────────┴──────────────────┴──────────────────┘

Expected Behavior

Consistent stats behavior to 3.2 and older and in-line with the logs metrics.

Steps to Reproduce the Behavior

The config I have is huge and would need severe redaction, if nothing is obvious I can work on a minimal reproducer.

Do you have any idea what may have caused this?

No response

Do you have an idea how to solve the issue?

No response

What is your configuration?

The backend configuration is extremely straightforward:

backend BKND
    balance uri whole
    hash-type consistent
    option httpchk GET /hcheck HTTP/1.1
    http-check send hdr X-Check check
    default-server inter 6s fastinter 2s fall 3 rise 5 maxconn 256
    server foo1.bar X.X.X.X:80 check weight 1
    server foo2.bar X.X.X.Y:80 check weight 2
    server foo3.bar X.X.X.Z:80 check weight 3

Some things that could be relevant:

    option                  redispatch
    option                  abortonclose
    retries                 3
    option idle-close-on-response
    http-reuse always

Output of haproxy -vv

This are in-house built packages, here's the relevant output from haproxy -vv (redacted a bit of sensitive output):

`HAProxy version 3.4.1-3e888a769 2026/06/25 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 2031.
Known bugs: http://www.haproxy.org/bugs/bugs-3.4.1.html
Build options : 
  TARGET  = linux-glibc
  CC      = cc
  CFLAGS  = -O2 -g -fwrapv
  OPTIONS = USE_GETADDRINFO=1 USE_OPENSSL_AWSLC=1 USE_ZLIB=1 USE_TFO=1 USE_NS=1 USE_QUIC=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_KTLS=1
  DEBUG   = 

Feature list : -51DEGREES +ACCEPT4 +ACME +BACKTRACE -CLOSEFROM +CPU_AFFINITY +CRYPT_H -DEVICEATLAS +DL -ECH -ENGINE +EPOLL -EVPORTS +GETADDRINFO +HAVE_TCP_MD5SIG -KQUEUE +KTLS -LIBATOMIC +LIBCRYPT +LINUX_CAP +LINUX_SPLICE +LINUX_TPROXY -LUA -MATH -MEMORY_PROFILING +NETFILTER +NS -OBSOLETE_LINKER +OPENSSL +OPENSSL_AWSLC -OPENSSL_WOLFSSL -OT +PCRE -PCRE2 -PCRE2_JIT +PCRE_JIT +POLL +PRCTL -PROCCTL -PROMEX -PTHREAD_EMULATION +QUIC -QUIC_OPENSSL_COMPAT +RT +SHM_OPEN -SLZ +SSL -STATIC_PCRE -STATIC_PCRE2 +TFO +THREAD +THREAD_DUMP +TPROXY +TRACE -WURFL +ZLIB
Detected feature list : +HAVE_WORKING_TCP_MD5SIG
`

Last Outputs and Backtraces

Additional Information

No response