From 04d328c7483d26fffd06815fbafd36a3dab8ad17 Mon Sep 17 00:00:00 2001
From: xormania <127287135+xormania@users.noreply.github.com>
Date: Tue, 14 Jul 2026 23:02:43 -0400
Subject: [PATCH] CI: add timeout-minutes backstop to the pytest matrix job

The cpu matrix job had no timeout-minutes, so a hung job runs until
GitHub's default 6-hour limit. This is not hypothetical: on run
29064865197 (2026-07-10), the native (ubuntu-latest) job hung and ran
from 02:36:34 to 08:36:50 before GitHub cancelled it at exactly the
6-hour cap, blocking the PR's status the whole time and burning a
runner for 6 hours.

Healthy runs are far below the new limit: across the 8 most recent
successful runs of this workflow, the slowest job was 16 minutes
(niche on ubuntu-latest), with catch-all on windows-latest typically
11-14 minutes. 60 minutes leaves ~4x headroom for cache-cold runs
(language-server downloads, npm installs) while cutting the worst-case
hang from 6 hours to 1.

Part of the timeout-hardening discussed in #1695.
---
 .github/workflows/pytest.yml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/.github/workflows/pytest.yml b/.github/workflows/pytest.yml
index 60beb1ff..6cbcf36c 100644
--- a/.github/workflows/pytest.yml
+++ b/.github/workflows/pytest.yml
@@ -56,6 +56,10 @@ jobs:
   cpu:
     name: ${{ matrix.batch }} (${{ matrix.os }})
     runs-on: ${{ matrix.os }}
+    # Backstop against hung jobs: without this, GitHub's default limit is 6 hours (observed in
+    # run 29064865197, where a hung job burned the full 6h). Healthy runs peak at ~16 minutes
+    # warm-cache; 60 leaves ample headroom for cache-cold runs.
+    timeout-minutes: 60
     # Marker groups are defined once here and combined in the "Compute marker expression" step.
     # The catch-all batch is derived as the negation of all named groups, so adding a language to
     # any group automatically removes it from catch-all -- the partition can never desync, and no