Флаки: test_auth_api.py — замер «худший сторонний запрос < 500 мс» падает на нагруженном раннере и роняет деплой tradein #3343

New issue

Closed

opened 2026-09-03 07:05:35 +00:00 by lekss361 · 0 comments

lekss361 commented

2026-09-03 07:05:35 +00:00

Owner

Что случилось. Deploy Trade-In run 9939 (merge #3342, 03.09.2026 06:57 UTC): job test упал на единственном тесте

tests/test_auth_api.py:829: AssertionError: худший сторонний запрос 544мс — API встаёт под флудом входа
1 failed, 5285 passed, 34 skipped

deploy из-за этого skipped, deploy-status красный, прод остался на образах от 01.09/02.09. Тот же сьют на том же коммите в pre-merge CI Trade-In / backend-tests прошёл за 5м02 — разница только в нагрузке раннера: в момент push-прогона параллельно шли build-frontend, build-browser и PR-джобы на трёх vps-runner'ах.

Почему это дефект теста, а не кода. Порог probe_latencies[-1] < 0.5 (абсолютные секунды wall-clock) на shared-раннере измеряет не «встаёт ли API под флудом», а свободен ли CPU у соседей. Тест из #2712 (bcrypt вне событийного цикла) проверяет правильную вещь неправильной метрикой.

Что сделать (варианты, выбрать один):

Относительный порог: latency пробы под флудом ≤ k × latency пробы без флуда (замерить baseline в том же тесте), а не абсолютные 500 мс.
Проверять механизм, а не время: что bcrypt действительно уходит в run_in_executor (мок executor'а / счётчик вызовов) и что event loop не блокируется (probe-корутина успевает N тиков).
Минимум: @pytest.mark.flaky(reruns=2) только для этого теста с причиной в коде — хуже 1 и 2, потому что прячет деградацию.

Не добавлять --deselect в deploy-tradein.yml — запрет прописан в самом workflow (#2722).

Восстановление 03.09: ручной workflow_dispatch deploy-tradein.yml.

**Что случилось.** Deploy Trade-In run 9939 (merge #3342, 03.09.2026 06:57 UTC): job `test` упал на единственном тесте ``` tests/test_auth_api.py:829: AssertionError: худший сторонний запрос 544мс — API встаёт под флудом входа 1 failed, 5285 passed, 34 skipped ``` `deploy` из-за этого skipped, `deploy-status` красный, прод остался на образах от 01.09/02.09. Тот же сьют на том же коммите в pre-merge `CI Trade-In / backend-tests` прошёл за 5м02 — разница только в нагрузке раннера: в момент push-прогона параллельно шли `build-frontend`, `build-browser` и PR-джобы на трёх vps-runner'ах. **Почему это дефект теста, а не кода.** Порог `probe_latencies[-1] < 0.5` (абсолютные секунды wall-clock) на shared-раннере измеряет не «встаёт ли API под флудом», а свободен ли CPU у соседей. Тест из #2712 (`bcrypt вне событийного цикла`) проверяет правильную вещь неправильной метрикой. **Что сделать (варианты, выбрать один):** 1. Относительный порог: latency пробы под флудом ≤ k × latency пробы без флуда (замерить baseline в том же тесте), а не абсолютные 500 мс. 2. Проверять механизм, а не время: что bcrypt действительно уходит в `run_in_executor` (мок executor'а / счётчик вызовов) и что event loop не блокируется (probe-корутина успевает N тиков). 3. Минимум: `@pytest.mark.flaky(reruns=2)` только для этого теста с причиной в коде — хуже 1 и 2, потому что прячет деградацию. Не добавлять `--deselect` в `deploy-tradein.yml` — запрет прописан в самом workflow (#2722). Восстановление 03.09: ручной `workflow_dispatch` deploy-tradein.yml.