Skip to content

fix: bound and parallelise the queue-time join - #58

Merged
aicayzer merged 1 commit into
mainfrom
fix/stats-queue-bounded
Sep 1, 2026
Merged

aicayzer merged 1 commit into
mainfrom
fix/stats-queue-bounded

Conversation

@aicayzer

@aicayzer aicayzer commented Sep 1, 2026

Copy link
Copy Markdown
Owner

What

runpool stats --queue made one serial gh api call per unique run, with no bound and no progress output. On this machine that was 1821 calls; killed at ten minutes, still running, having printed a single line. A command that is working and a command that is stuck looked the same.

Closes #56, closes #57.

Changes

  • Bounded by default. The join covers the last 7 days. --days N widens or narrows it, --all removes the limit. A run outside the window is dropped before it can cost a call.
  • Parallel. Calls run 8 at a time (RUNPOOL_JOIN_JOBS). Each worker writes its own file rather than a shared pipe, because concurrent writers interleave mid-line and a torn row would silently corrupt the join.
  • Legible. It says how many runs it is fetching and at what concurrency, then marks each one off.
  • Docs for Nothing surfaces a pools file that disagrees with the running pool #57. The pools file is intent, the running pool is state, and apply --dry-run reconciles them. set-count deliberately does not write the file, so they disagree after every resize. That was already the design; it just was not written down.

Measured

before after
740 runs (7-day default) did not finish 66s
179 runs (--days 1) did not finish 19s

Tests

New tests/stats-queue-window.sh, offline with a stubbed gh. Covers the window actually cutting API calls, the default staying bounded, the progress reporting, and flag validation on both entry points. Verified it fails when the default is made unbounded again.

All five suites pass; shellcheck --severity=warning and bash -n clean.

`stats --queue` made one serial API call per unique run with no bound and
no output, so on a machine with real history it did not finish and looked
identical to a hang. Observed at 1821 calls, killed at ten minutes.

The join now covers the last 7 days by default, with `--days N` to widen
or narrow it and `--all` for no limit, and runs its calls in parallel
(`RUNPOOL_JOIN_JOBS`, default 8). It reports how many runs it is fetching
before it starts and marks each one off, so a long join is legible rather
than silent. 740 runs now complete in about a minute.

Also documents what was already true but unwritten: the pools file is
intent, the running pool is state, and `apply --dry-run` is where the two
are reconciled. `set-count` deliberately does not write the file, so they
disagree after every resize, and that is the design rather than drift to
repair.

Closes #56
Closes #57
@aicayzer
aicayzer merged commit fad0f26 into main Sep 1, 2026
2 checks passed
@aicayzer
aicayzer deleted the fix/stats-queue-bounded branch September 1, 2026 10:12
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.

Nothing surfaces a pools file that disagrees with the running pool stats --queue does not finish: 1821 serial API calls, no bound, no progress

1 participant