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
..
assert_tests_ran.py	ci(e2e): run the access_control canary on harness changes and name failed tests	2026-09-05 18:46:51 -07:00
down.sh	ci(e2e): run a PR's changed e2e tests three times behind a human-approved environment	2026-09-02 14:53:40 -07:00
secrets_to_env.py	fix(e2e-changed): keep the gate off suites the stack cannot run	2026-09-05 21:03:50 -07:00
select_tests.py	test(e2e): rewrite the Redis timeout test as a locust chaos load test	2026-09-10 21:55:23 -07:00
up.sh	fix(e2e): wait for every gateway before using a new model and keep the network rerun	2026-09-05 16:10:40 -07:00