mirror of
https://github.com/lrnselfreliance/wrolpi.git
synced 2026-10-26 10:51:36 -04:00
9d24d67f59
The first CI run that actually enforced the timeout failed sixteen tests, and not one of them had hung. Every failure sat at exactly 30.0s, and the successes directly beneath them tell the story: test_get_refresh_progress passed at 29.9s, test_create_playlist at 29.8s, test_configs_crud at 29.4s. A cluster of refresh/worker tests straddles the limit on CircleCI's 4 vCPU box, which runs this suite in about twice the wall-clock of a dev machine -- the ones that passed did so by a tenth of a second, which is luck, not headroom. Thirty seconds was never a viable limit there; it only looked fine locally because nothing local exceeds it. So the limit is a hang detector, not a performance budget. 120s is roughly four times the slowest legitimate test observed on CI: still short enough to name a hung test long before CircleCI kills the job, and long enough to leave slow-but-working tests alone. A limit that fires on healthy tests only trades one unreliable signal for another. Also: controller-tests.yml carried the same `pull_request: branches: [master]` filter that jest-tests.yml did, so it never ran on a pull request into any other branch. That is why Controller Tests is missing from the checks on the very pull request that moved it to Python 3.13 -- the change could not be verified by the run containing it. Now unfiltered, like jest-tests. Not verified locally: this machine is under a load average of 45 from unrelated work, so the suite takes more than four times its usual wall-clock here and any timing measurement is meaningless. The change is strictly more permissive than what already passed at 30s, so it cannot introduce a failure, and CI is the environment in question -- it decides this one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
22 lines
1.1 KiB
INI
22 lines
1.1 KiB
INI
[pytest]
|
|
asyncio_mode = auto
|
|
testpaths =
|
|
wrolpi
|
|
modules
|
|
asyncio_default_fixture_loop_scope = function
|
|
# Do not remove timeout - tests should not run forever.
|
|
#
|
|
# This is a hang detector, not a performance budget. It was 30s, but the plugin was never
|
|
# declared in requirements.txt, so CI installed without it and the limit had never actually been
|
|
# applied there. The first run that enforced it failed sixteen tests, every one of them at
|
|
# 30.0s and none of them hung: CircleCI's 4 vCPU box runs this suite in roughly twice the
|
|
# wall-clock of a dev machine, and a cluster of refresh/worker tests sits at 28-30s there --
|
|
# test_get_refresh_progress passed at 29.9s and test_create_playlist at 29.8s, which is luck
|
|
# rather than headroom.
|
|
#
|
|
# 120s is about four times the slowest legitimate test observed on CI, so it still catches a
|
|
# genuine hang long before CircleCI kills the job, while leaving slow-but-working tests alone.
|
|
# Raise it if CI grows slower; a named timeout failure is the point, and a limit tight enough to
|
|
# fire on healthy tests just trades one unreliable signal for another.
|
|
timeout = 120
|
|
timeout_method = signal
|