Add idempotency_token to job_runs resource#5882
Open
radakam wants to merge 6 commits into
Open
Conversation
Collaborator
Integration test reportCommit: 7faf08b
10 interesting tests: 4 SKIP, 3 KNOWN, 2 flaky, 1 RECOVERED
Top 10 slowest tests (at least 2 minutes):
|
acf313b to
3a5ea16
Compare
Job runs now send an automatic idempotency_token on run-now so a retried deployment reuses the existing run instead of triggering a duplicate. The token is the hex SHA-256 of the RunNow request (job_id cleared of the token itself), computed in DoCreate on a copy so it is never persisted to state. A user-set idempotency_token is rejected at validation time, and the local testserver now deduplicates run-now by token so the behavior is covered by tests.
Covers the idempotency token end-to-end: deploy triggers a run, the run is dropped from local state (keeping the job so job_id and the derived token stay stable), and a redeploy re-issues run-now. The backend dedupes on the token and returns the existing run, so no duplicate is created. Drop the DoCreate-level TestJobRunIdempotentCreate since the acceptance test now covers that path end-to-end; the token helper's unit tests remain.
Add WaitAfterCreate to the job_runs direct-engine resource: it polls
until the run reaches a terminal state and returns the run's output
fields (state, run_id, run_page_url, ...) so downstream resources can
read e.g. ${resources.job_runs.x.state.result_state}. A FAILED result
is surfaced as readable state rather than failing the deploy; only
INTERNAL_ERROR fails it.
Add the wait_output acceptance test (a downstream job reads result_state,
and a redeploy stays a no-op so the resolved value doesn't churn), and
extend idempotent_recreate to cover both mid-run retry paths: a lost run
id (token dedupes run-now) and a recorded run id (retry is a no-op).
Regenerate the redeploy golden, which now shows the run TERMINATED.
51dca78 to
66ca15a
Compare
Add a changelog fragment for the idempotency + wait-for-completion work. The shared CRUD harness compared WaitAfterCreate's result against the read taken right after DoCreate. A job run transitions RUNNING -> TERMINATED while we wait, so compare against a fresh read taken after the wait instead, mirroring how DoUpdate is already validated.
Contributor
Approval status: pending
|
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
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.
Changes
Extends the experimental (direct-engine)
job_runsresource with:WaitAfterCreatepolls until the run reaches a terminal state (TERMINATED/SKIPPED); onlyINTERNAL_ERRORfails the deploy, other result states surface as readable state.state,run_id,run_page_url, ...) is exposed so downstream resources can reference e.g.${resources.job_runs.<name>.state.result_state}.idempotency_token(SHA-256 of theRunNowrequest) is computed automatically and sent onrun-now, so a retried deploy reuses the existing run instead of starting a duplicate. A user-setidempotency_tokenis rejected with a clear validation error.Also hardens the shared direct-engine CRUD test so
WaitAfterCreate's result is compared against a fresh read taken after the wait (a run legitimately transitions RUNNING → TERMINATED).Why
Triggering a job during
bundle deploypreviously required scripts outside the bundle, and re-running a run without waiting left output fields unavailable to dependent resources and risked duplicate runs on retry. This makesjob_runsdeployments reliable and composable (Milestone 2: idempotency + wait for completion).Tests
idempotent_recreate— retry mid-run (with and without a recorded run id); assertsrun-nowfires with one shared token and no duplicate run is created.wait_output— downstream job reads the run's resolvedresult_state; redeploy is a no-op (no perpetual drift).