What
None of the jobs in .github/workflows/ci.yml set timeout-minutes, so they inherit GitHub's 6-hour default. A test that hangs (rather than fails) keeps a runner occupied for hours and leaves the PR check sitting at pending with no signal about what went wrong.
Where
.github/workflows/ci.yml:60 — the backend job (and the frontend / secrets jobs likewise).
Why it matters
This is not hypothetical: PR #344 hit exactly this. StackExchange.Redis 2.13 makes a Messaging test hang forever (#349), and the backend check stayed pending indefinitely rather than failing. During triage the check gave no usable signal at all — the hang had to be reproduced locally to discover it. A bounded job would have turned a silent multi-hour stall into a fast, legible failure.
Suggested fix
Add a timeout-minutes to each CI job, sized generously against observed runtimes (backend is ~5 min today, so 20 would be ample). Consider also a per-test timeout in the MSTest config so a hang surfaces as a failing test rather than a dead job.
What
None of the jobs in
.github/workflows/ci.ymlsettimeout-minutes, so they inherit GitHub's 6-hour default. A test that hangs (rather than fails) keeps a runner occupied for hours and leaves the PR check sitting atpendingwith no signal about what went wrong.Where
.github/workflows/ci.yml:60— thebackendjob (and thefrontend/secretsjobs likewise).Why it matters
This is not hypothetical: PR #344 hit exactly this.
StackExchange.Redis2.13 makes a Messaging test hang forever (#349), and thebackendcheck stayedpendingindefinitely rather than failing. During triage the check gave no usable signal at all — the hang had to be reproduced locally to discover it. A bounded job would have turned a silent multi-hour stall into a fast, legible failure.Suggested fix
Add a
timeout-minutesto each CI job, sized generously against observed runtimes (backendis ~5 min today, so 20 would be ample). Consider also a per-test timeout in the MSTest config so a hang surfaces as a failing test rather than a dead job.