🤖 Auto-generated by Claude Opus 5 (claude-opus-5) via Claude Code — NOT human-reviewed. The run data below came from the Actions API; the local hangs were observed directly.
build_tests (3.13) intermittently hangs and is eventually cancelled. No other Python version in the matrix does it.
On CI
Across the last 25 build_tests runs, three jobs were cancelled. All three are 3.13:
| Run |
Job |
| 34149367298 |
build_tests (3.13) |
| 34155833425 |
build_tests (3.13) |
| 34273663729 |
build_tests (3.13) |
The last of those ran 30m19s before being cancelled while 3.10, 3.11, 3.12 and 3.14 all passed in under two minutes on the same commit. Re-running that single job on the same commit passed in 1m45s, so it is not the code under test.
Locally
Reproduced twice on 3.13 with a venv built from the test extra, pytest test/unittests on an otherwise green tree:
- one run completed in ~96s; the next two were still running at the 600s cap and had to be killed
- a later run sat at the same point, roughly 28% through the suite, for over 11 minutes with no output
The same tree on 3.12 completes in ~77s every time.
Why it matters beyond the wasted minutes
A hung job reads as a red PR. Two pull requests were reported red today on nothing but this, and the natural response to a red check is to look for a cause in the diff. It also occupies a runner for half an hour each time.
Not yet known
Which test hangs. The progress bar stops around the same fraction of the suite each time, so bisecting by file should find it quickly, but the cancelled job uploads no report and the local runs were killed before pytest could name the test. Running 3.13 with -x --timeout per test, or with faulthandler dumping on a timer, would name it on the next occurrence.
build_tests (3.13)intermittently hangs and is eventually cancelled. No other Python version in the matrix does it.On CI
Across the last 25
build_testsruns, three jobs were cancelled. All three are 3.13:build_tests (3.13)build_tests (3.13)build_tests (3.13)The last of those ran 30m19s before being cancelled while 3.10, 3.11, 3.12 and 3.14 all passed in under two minutes on the same commit. Re-running that single job on the same commit passed in 1m45s, so it is not the code under test.
Locally
Reproduced twice on 3.13 with a venv built from the
testextra,pytest test/unittestson an otherwise green tree:The same tree on 3.12 completes in ~77s every time.
Why it matters beyond the wasted minutes
A hung job reads as a red PR. Two pull requests were reported red today on nothing but this, and the natural response to a red check is to look for a cause in the diff. It also occupies a runner for half an hour each time.
Not yet known
Which test hangs. The progress bar stops around the same fraction of the suite each time, so bisecting by file should find it quickly, but the cancelled job uploads no report and the local runs were killed before pytest could name the test. Running 3.13 with
-x --timeoutper test, or withfaulthandlerdumping on a timer, would name it on the next occurrence.