Wait for a job’s terminal state

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A video request is accepted as J3 with queued status and no available artifact. The teaching budget is three polls, using the same job ID. Separate acceptance, execution, terminal state and retrieval rather than treating creation as a video.

Mechanism

Persist ID/request identity and poll under service intervals, limits and budget. Retrieve/check output after completed; report failed errors; return resumable pending state when budget expires. Cancellation follows agreed permission, without silent cancellation or duplicate creation to finish a reply.

Bad example

Publish a video-success claim as soon as J3 is created. Recreate or cancel slow jobs automatically and discard their IDs.

Good example

Save J3 and poll up to three times under the teaching service contract, recording queued/running/completed/failed. Claim usable output only after completed and retrieved. Report failures or pending with J3/current checks at budget expiry. Do not create duplicates; cancellation stays within agreed rules/permission. Verify temporary output-URL availability separately.

Why the change matters

Acceptance starts work without establishing output existence. Stable ID and explicit states distinguish waiting/failure/retrieval and avoid duplicate cost or confused results.

Observable expectation

Queued→running→completed permits retrieval; queued→running→running remains pending; failed has no successful artifact.

Check repeated J3 identity, bounded polls and no unauthorized publication; accessible URLs are not permanently available. No real video is generated.

Limits

Actual state names, timing, cancellation and link expiry follow current service contracts. The frozen seven-day statement is not a current guarantee. Waiting budgets change neither service outcomes nor artifact checks.