Skip to content

fix(ci): give the unit step a deadline so a stuck jest reports instead of sulking - #264

Merged
Miracle656 merged 1 commit into
Miracle656:mainfrom
Daveeee-tech:ci/unit-step-deadline
Oct 19, 2026
Merged

Miracle656 merged 1 commit into
Miracle656:mainfrom
Daveeee-tech:ci/unit-step-deadline

Conversation

@Daveeee-tech

Copy link
Copy Markdown
Contributor

Why

npm test on main never finishes. The Unit tests step 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:

  build:
    name: Typecheck & build
    timeout-minutes: 20
    ...
      - name: Unit tests
        run: timeout -k 30s 900s npm test --if-present

The step gets 15 minutes with KILL 30 seconds behind it — a jest held open by a timer may not answer TERM, 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 test should report in well under the step's 15 minutes and the deadline simply stops being visible.

…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.
@drips-wave

drips-wave Bot commented Oct 18, 2026

Copy link
Copy Markdown

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., Closes #123), or by clicking a button below:

Issue Title
#237 The offramp rate is naira per dollar and nothing says so Link to this issue

ℹ️ Learn more about linking PRs to issues

@Miracle656 Miracle656 left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nine lines, and the comment earns every one of them.

- name: Unit tests
  run: timeout -k 30s 900s npm test --if-present

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

@Miracle656
Miracle656 merged commit 740bb18 into Miracle656:main Oct 19, 2026
1 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants