From a1f9f4cbe839a8bd4bcf605bbcf44effddd3724f Mon Sep 17 00:00:00 2001 From: Kerry Lu Date: Fri, 11 Sep 2026 13:45:11 -0700 Subject: [PATCH] test(e2e): tighten chaos latency ceilings to 1s/2s/3s Local runs measured p50 0.19s, p90 0.23s, p99 0.69s, so 2s/3s/5s left several times that as slack. 1s/2s/3s keeps a comfortable margin while catching a smaller regression than the looser ceilings would have. Co-Authored-By: Claude Code --- tests/e2e/load/test_redis_chaos_e2e.py | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/e2e/load/test_redis_chaos_e2e.py b/tests/e2e/load/test_redis_chaos_e2e.py index c800ccb0e51..518bbd262a9 100644 --- a/tests/e2e/load/test_redis_chaos_e2e.py +++ b/tests/e2e/load/test_redis_chaos_e2e.py @@ -84,11 +84,11 @@ CHAOS_CPU_PER_REQUEST_RATIO_CEILING: Final = 2.0 # the breaker opens, a request skips Redis rather than waiting on its socket timeout, so the chaos # phase can come in faster than baseline (local runs measured p90 at 0.61x) and a ratio passes on a # phase that was never slow. What a user actually cares about is the wall-clock number, which these -# hold directly. Calibrated from local runs whose worst chaos phase was p50 0.66s, p90 0.74s, p99 -# 1.20s and 3.4 KB of log per request, then left roughly 3x loose for a shared CI runner. -CHAOS_P50_LATENCY_CEILING_SECONDS: Final = 2.0 -CHAOS_P90_LATENCY_CEILING_SECONDS: Final = 3.0 -CHAOS_P99_LATENCY_CEILING_SECONDS: Final = 5.0 +# hold directly. Calibrated from local runs whose worst chaos phase was p50 0.19s, p90 0.23s, p99 +# 0.69s and 3.5 KB of log per request, with several times that left as slack for a shared CI runner. +CHAOS_P50_LATENCY_CEILING_SECONDS: Final = 1.0 +CHAOS_P90_LATENCY_CEILING_SECONDS: Final = 2.0 +CHAOS_P99_LATENCY_CEILING_SECONDS: Final = 3.0 CHAOS_LOG_BYTES_PER_REQUEST_CEILING: Final = 12_000.0 DRAIN_TIMEOUT_SECONDS: Final = 30.0