You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CI: hung Windows pytest leg can still end cancelled with no log (faulthandler_exit_on_timeout not proven) #1032
#1014 added faulthandler_timeout = 900 plus a step-level timeout-minutes: 25 on the "Run tests" / "Run the full suite against the compiled hooks" steps in .github/workflows/tests.yml, so a hung test's traceback and the step-timeout error land in a log that is kept and uploaded as an artifact.
That fix is proven on Linux only: #1022's own round-2 proof (run 38122057767, job 114445674357, a deliberately hanging test with faulthandler_timeout temporarily lowered) shows the faulthandler traceback naming the stuck test in the kept log, followed by ##[error]The action 'Run tests' has timed out after 25 minutes. -- i.e. the step's own timeout-minutes is what keeps the log.
What is NOT proven: the original failure mode #1014 was filed for is a Windows job ending cancelled with no log at all, after the step ran past its own timeout (run 38122057767, job 114418645594: ~33.6 min past a 25-minute timeout, job ended cancelled, no log). #1022 removed a temporary faulthandler_exit_on_timeout = true setting that was meant to make pytest _exit the PROCESS itself well inside the step bound (bypassing whatever held it on Windows), because the round-2 proof above did not show it doing anything: the step timeout fired and ended the step before any process-level exit was observed. Nothing in #1022 demonstrates that the step-level timeout-minutes: 25 reliably ends the step (rather than the whole job going cancelled with no log) on a genuinely hung Windows leg -- only a Linux leg was exercised with a real hang.
What would close this
A CI run (or targeted proof commit, the same pattern #1022 used) on windows-latest with a deliberately hanging test and the step timeout in place, showing either:
the step ends failed (not the job cancelled) and the log, including the faulthandler traceback, is uploaded as an artifact; or
it still goes cancelled with no log, in which case faulthandler_exit_on_timeout (or another Windows-specific mechanism) needs to be reinstated and this time shown to work with a genuine hang, not just the 8s proof that only showed the dump firing.
Filed per #1022's own report, which left this gap open rather than claiming it fixed.
Activity
Chaitanyaputhran commentedon Oct 17, 2026
Hi @fdaviddpt ,
Can you assign this to me?