feat(cli): run test sessions via the async v1 scheduling API [RED-680] [show] - #1420
Merged
Merged
Conversation
sorccu
changed the title
sorccu
changed the title
Member
Author
|
The failing |
checkly test now runs sessions via POST /v1/test-sessions/run, which dispatches the check runs in the background after the 202. The CLI watches the returned scheduling operation (long-poll with 408 retries, aborted once the run settles) and fails the run immediately with the server's error when dispatch fails — previously a server-side dispatch failure produced no MQTT results and the CLI hung for the full per-check timeout (600s, or 1200s for Playwright) before printing a generic timeout. In --detach mode the CLI confirms dispatch reached a terminal state before detaching, so a dispatch failure still exits non-zero like the synchronous endpoint did. Requires the backend scheduling endpoints (checkly/monorepo#2795) — do not release before they are live in production. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HFcrNm7uzzkD1p87Nf9AhP
sorccu
force-pushed
the
simo/red-680-fail-fast-on-scheduling-failure
branch
from
July 27, 2026 12:05
90db48b to
5f3aa74
Compare
sorccu
changed the title
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Linear: RED-680
What
checkly testandcheckly trigger --recordnow run test sessions through the new asynchronous scheduling API instead of the legacy synchronous endpoint:TestSessions.run()callsPOST /v1/test-sessions/run. The 202 arrives as soon as the session is validated and persisted — the backend dispatches the checks in the background — and additionally carries aschedulingIdidentifying the dispatch operation.getSchedulingCompletionandpollSchedulingUntilComplete(30s long-poll onGET /v1/test-sessions/scheduling/{schedulingId}/completion, 408 → retry).Keeping dispatch failures visible
With the synchronous endpoint, a dispatch failure (bad snippet, missing private location, queue trouble) surfaced in the HTTP response itself. Under the async contract the 202 predates dispatch, so without anything else a background dispatch failure would mean: 202, then no results, until the per-check timeout expires with a generic message. To keep the old failure visibility:
watchSchedulingpromise polls the scheduling operation and rejects withTestSessionSchedulingFailedError(code: SCHEDULING_ERROR | ABANDONED) the moment dispatch fails — including when the scheduling worker dies and the backend reaper reclaims the operation. The run exits non-zero within seconds, with the real error.--detachawaits scheduling success before emitting DETACH, so detach mode cannot exit zero for a session that was never dispatched.Behavior notes (accepted)
--detachgains a few seconds of latency (one completion poll round-trip).Backend dependency
Requires the new v1 test-session scheduling endpoints on the Checkly backend (internal change, tracked under RED-680; in the merge queue at the time of writing). Blocked from release — not from merge — until that backend change is live in production: the CLI calls v1 unconditionally, with no fallback to the legacy endpoint (deliberate decision). Merging is safe; releasing before the backend is deployed would break
checkly testfor everyone on the new version.🤖 Generated with Claude Code
https://claude.ai/code/session_01HFcrNm7uzzkD1p87Nf9AhP