Skip to content

CI: hung Windows pytest leg can still end cancelled with no log (faulthandler_exit_on_timeout not proven) #1032

Open

Description

@fdaviddpt

#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.

[AI-generated]

Activity

  1. added
    priority:mediumRecurring cost; compounds if unfixed
    cohort-26Open at the v0.43.1 tag, 2026-10-11. Frozen: nothing joins a cohort.
    on Oct 11, 2026
  2. Chaitanyaputhran commented on Oct 17, 2026

    @Chaitanyaputhran

    Hi @fdaviddpt ,
    Can you assign this to me?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    cohort-26Open at the v0.43.1 tag, 2026-10-11. Frozen: nothing joins a cohort.priority:mediumRecurring cost; compounds if unfixed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions