Repository navigation
fix(ci): give the unit step a deadline so a stuck jest reports instead of sulking - #264
Conversation
…d of sulking `npm test` finishes in about 22 seconds. Since the per-network status work landed it has not reported at all: every build job has sat on that step with nothing to show for it, because the job declares no timeout-minutes, GitHub's six-hour default applies, and a job that is still running has no downloadable log. A hang is then indistinguishable from CI being slow, both from outside and from in here — and eight runners on this repo are currently occupied by exactly that. Two deadlines, one at each level. The step gets 15 minutes with a KILL 30 seconds behind it, because a jest held open by a timer may not answer TERM, and a killed process flushes the output it already produced. That flush is the whole point: it is what turned "CI is hanging" into a stack trace naming the indexer loop that crashes on an absent DATABASE_URL, schedules a restart ten seconds out, and repeats forever. The job gets 20 minutes so a step that ignores both still ends. This does not fix the hang, and it is not pretending to. Miracle656#257 carries the fix, in `startAllIndexers` and its timers. Without this commit, finding it would have taken the same six hours per attempt, indefinitely.
|
Hey @Daveeee-tech! 👋 It looks like this PR isn't linked to any issue. If this PR is for one of the issues assigned to you as part of a Wave, please link it to ensure your contribution is tracked properly. You can do this by adding a keyword to the PR description (e.g.,
|
Miracle656
left a comment
There was a problem hiding this comment.
Nine lines, and the comment earns every one of them.
- name: Unit tests
run: timeout -k 30s 900s npm test --if-presenta stuck step with no deadline holds a runner for six hours while its log stays unreadable, which is how a hang gets mistaken for CI being slow
That is the real failure, and it is worse than the six wasted hours: a job that hangs produces no readable output until it ends, so the run looks slow rather than broken, nobody investigates, and the actual error — an open handle, usually — is never seen. Killing it at fifteen minutes flushes whatever was collected, which turns an invisible hang into a diagnosable failure.
The numbers are argued rather than picked: the suite finishes in about half a minute, so anything still running at fifteen minutes is stuck, not slow. And -k 30s sends SIGKILL thirty seconds after SIGTERM, so a process ignoring the polite signal still dies.
timeout-minutes: 20 on the job sits outside the 15-minute step timeout, which is the right order: the step's own deadline fires first and produces output, and the job-level one is the backstop if something outside the step wedges.
This is the sort of thing that only gets written by someone who has waited on a hung run. Merging.
Why
npm testonmainnever finishes. TheUnit testsstep of the CI job hangs until GitHub's six-hour default, and because a still-running job has no downloadable log, the only way to learn what it was stuck on was to make it fail on purpose.The underlying bug is fixed separately, in #257: the indexer's crash-restart chain kept the process alive forever. This pull request is only about never being blind to that class of failure again.
What
Two deadlines, one at each level:
The step gets 15 minutes with
KILL30 seconds behind it — a jest held open by a timer may not answerTERM, and a killed process still flushes what it produced. That flush is the point: it is what turned "CI is hanging" into a stack trace naming the indexer loop. The job gets 20 minutes so a step that ignores both still ends.Why this is its own pull request
It touches
.github/workflows/ci.yml, which means fork runs wait for a maintainer's approval — and it would have dragged #257's CI with it. Keeping it here lets #257 stay reviewable as product code and lets this be approved for what it is: a test harness change, nothing else. Once #257's fix is in,npm testshould report in well under the step's 15 minutes and the deadline simply stops being visible.