Skip to content

Add sp run wait to block until runs finish - #3

Open
cfsmp3 wants to merge 1 commit into
masterfrom
feat/run-wait
Open

Add sp run wait to block until runs finish#3
cfsmp3 wants to merge 1 commit into
masterfrom
feat/run-wait

Conversation

@cfsmp3

@cfsmp3 cfsmp3 commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Why

Anything that cares about a run's outcome — a CI script, an agent, a developer watching a PR — currently has to write its own poll loop against sp run ls. Each one picks its own interval and its own idea of which statuses are terminal, and they all get it slightly differently.

What

sp run wait RUN_IDS... [--interval N] [--timeout N] [--quiet]

Polls until every named run leaves queued/running, then prints the final records.

  • Progress goes to stderr, so the JSON payload on stdout stays pipeable.
  • The exit code carries the result: 0 every run succeeded, 1 any run failed or was canceled, 2 timeout. A script can gate on the outcome without parsing anything.
  • An unrecognised status counts as terminal, not as "keep polling" — a new server-side state can't leave the command spinning until timeout.

Notes

Statuses live in constants.py (RUN_PENDING_STATUSES, RUN_UNSUCCESSFUL_STATUSES) rather than inline, since wait and the existing listing code need to agree on what "done" means.

Defaults are 30s interval / 3600s timeout.

Testing

6 new tests covering: all-success, mixed failure, timeout, unknown-status-is-terminal, --quiet, and multi-run polling. Full suite 216 pass; isort/pycodestyle/pydocstyle/mypy clean.

Also exercised against the live deployment on two real queued runs — it correctly held through ~85 minutes of queue latency and exited 2 with the still-pending IDs named.

Every consumer of this CLI that cares about a run's outcome -- CI scripts,
agents, a developer watching a PR -- currently has to write its own poll loop,
and each one picks its own interval and its own idea of which statuses are
terminal.

`sp run wait 9476 9477` polls until every run leaves queued/running, then
prints the final records. Progress goes to stderr so the payload on stdout
stays pipeable, and the exit code carries the result: 0 when every run
succeeded, 1 when any failed or was canceled, 2 on timeout. That lets a script
gate on the outcome without parsing anything.

An unrecognised status counts as terminal rather than as "keep polling", so a
new server-side state cannot leave the command spinning forever.
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.

1 participant