release.yml has no timeout-minutes, so a stuck job hangs for 6 hours and blocks publish #187

Hit while cutting v2.4.1.

What happened

The release workflow's build job hung for 3h11m on Run tests with coverage. Prior cuts (v2.2.1, v2.3.0, v2.4.0) all completed in roughly 4–5 minutes.

The tagged commit was healthy — running the exact release command locally on 4f81744 gave 2737 passed, 3 skipped, coverage 85.86% against a 60% gate. So this was a runner/network stall, not the code.

Cancelling and re-running the same run cleared it.

The gap

.github/workflows/release.yml sets no timeout-minutes on any job, so a stuck job runs until GitHub's default 6-hour ceiling. Because publish and github-release both needs: the previous job, a single stall silently blocks the entire release for six hours before anything fails.

pipeline-bootstrap.yml:74 is the only workflow in the repo that sets a timeout (30). test.yml has none either, though the blast radius there is smaller — a stuck PR check is visible and doesn't gate a publish.

Why it matters more here than elsewhere

The tag push is the publish: it builds, ships to PyPI via trusted publishing, and creates the GitHub release. A silent 6-hour hang on that path means a release appears tagged but never actually ships, and nothing surfaces the problem — I only noticed because I compared the run's start time against previous cuts.

Suggested scope

• Add timeout-minutes to each job in release.yml. The build job's real work is ~5 min, so something like 20–25 leaves generous headroom while failing fast on a stall.
• Consider the same for test.yml.
• Consider adding workflow_dispatch to release.yml. Today the only trigger is a tag push, so recovering from a failed release run means either gh run rerun (worked here) or deleting and re-pushing a published tag, which rewrites a ref that may already have been fetched.

Not urgent

The 6-hour ceiling is a backstop that does eventually fire, and gh run rerun recovers without touching the tag. Filing so the fix gets made deliberately rather than appended untested to a release that is mid-flight — CI plumbing that has never been exercised is exactly what failed here.