Kerry Lu 33ec56ed75 test(e2e): rewrite the Redis timeout test as a locust chaos load test ... The sequential version sent one request at a time, so a Redis outage never reached the concurrency where the failed-tracking alert body actually grows. This drives the proxy with locust against one model group of three mock deployments, two failing at order 1 and one serving at order 2, so every request spends its retries on the failing pair and lands on the serving deployment through the order-based fallback. Two phases, a healthy baseline and a CLIENT PAUSE WRITE window, and every request must succeed in both. Latency, RSS and CPU are reported as p50/p90/p99 per phase rather than asserted on: RSS and CPU come from psutil on the proxy's process tree, since a multi-worker proxy serves /metrics from the prometheus multiprocess collector and that drops the process collector's series. Thresholds stay open until weekly runs give real baselines. Co-Authored-By: Claude Code <noreply@anthropic.com>		2026-09-10 21:55:23 -07:00
..
record_replay_ci_config.yml	ci(e2e): record the e2e suite weekly and replay it on weekdays with zero egress (#38163)	2026-08-24 23:49:03 -04:00
redis_chaos_ci_config.yml	test(e2e): rewrite the Redis timeout test as a locust chaos load test	2026-09-10 21:55:23 -07:00
stage_mirror_ci_config.yml	ci(e2e): declare the embedding model the access_control canary calls	2026-09-05 18:58:07 -07:00