test(ci): развести «нагрузку не создать» и «защита сломана» в двух флапающих гейтах (#2783) #2789

Merged
bot-backend merged 1 commit from fix/auth-flood-test-flake into main 2026-08-07 10:35:15 +00:00

1 commit

Author SHA1 Message Date
7e21ff2af9 test(ci): развести «нагрузку не создать» и «защита сломана» в двух гейтах (#2783)
All checks were successful
CI Trade-In / changes (pull_request) Successful in 17s
CI / changes (pull_request) Successful in 17s
CI Trade-In / browser-tests (pull_request) Has been skipped
CI Trade-In / frontend-checks (pull_request) Has been skipped
CI / frontend-tests (pull_request) Has been skipped
CI / openapi-codegen-check (pull_request) Successful in 2m58s
CI Trade-In / backend-tests (pull_request) Successful in 5m15s
CI / backend-tests (pull_request) Successful in 16m3s
Оба теста красили ЧУЖИЕ PR-ы по таймингу раннера, а на правиле «зелёный CI =
можно мержить» здесь держится весь самомерж. Диагнозы разные, поэтому и правки
разные.

1) tradein auth-флуд (`test_login_flood_capped_by_rate_…`). Утверждение про
потолок верное — подводило ПРЕДУСЛОВИЕ `len(codes) > connections`: «каждое из ста
соединений успело сходить дважды за секунду» мерит скорость раннера, а не
нагрузку. На занятом первый круг из ста запросов сам съедает всю секунду, и
невыполненное предусловие давало красный, неотличимый от настоящей поломки
потолка. Замер: свободная машина — 0 падений из 20 (~800 ответов/с), под load
average ~185 — 10 из 15, и в каждом флуд всё равно предлагал 55-80 запросов/с
против порога 30/с, то есть мерить БЫЛО на чем.

Теперь предусловие содержательное и с тем же порогом, с которым сверяется
вердикт: пока флуд предлагает меньше `ceiling × 1.5`, следующее утверждение
зелено даже без потолка вовсе — значит измерения нет, и красный говорит «раннер
не потянул», а не «потолок сломан». Остальные четыре утверждения не тронуты.

2) backend weather_cache. Здесь подводило САМО утверждение: тест требовал
«ровно один сетевой вызов на 16 потоков», а код (#1370) прямым текстом выносит
вызов за lock и обещает обратное — «может породить несколько параллельных
запросов… приемлемо». Зелёным он был по везению GIL: 200 штормов дали 2 вызова
один раз (~0.5% — этим и покрасило #2781), а при `setswitchinterval(1e-6)`
больше одного вызова дали 197 штормов из 200.

Тест приведён к тому, что код правда гарантирует: значение у всех потоков одно,
сетевых вызовов не больше числа участников, ключ один, и ПОСЛЕ шторма кэш
отвечает без сети. Код не тронут: поведение объявлено приемлемым в #1370 с
обоснованием; настоящий single-flight (per-key lock) — отдельная задача с
отдельным обоснованием, а не побочный эффект правки теста.

Оба сторожа проверены на способность краснеть: снятый гейт насыщения + пул мимо
настройки → «957 сверок/с при потолке 20/с» (и под нагрузкой тоже краснеет, на
том же прогоне, где раньше падало предусловие); потерянная запись в кэш / чужой
ключ / мёртвый TTL → три разных красных сообщения.

Refs #2783
2026-08-07 15:12:30 +05:00