What a queue claim readback actually proves

Choose work from job state and content state#

The worker accepts scheduled or targeted requests and sets a run identity, batch size, retry limit and claim timeout. Selection excludes finished jobs and active claims. Retryable failures enter only when explicitly enabled or targeted.

A queue row isn't the whole story. The selector also checks for existing descriptions, prompts and the expected text file. An explicit revision request can reopen a package, but an ordinary run shouldn't treat completed content as missing merely because another stage failed.

Check ownership at the point of processing#

The worker creates a token from owner, run and job IDs, upserts the job as in progress, and reads the row again. Context preparation requires both the matching token and expected state. If another claim overwrote the row before this read, the worker takes the failure path.

The write and read are still separate operations. The upsert doesn't require the previous owner or state, and another worker can act between them. Readback therefore detects one lost-ownership case; it doesn't provide an atomic reservation or an exactly-once guarantee.

Preserve what succeeded inside a failed job#

Failure results include their step, code and retry or terminal flags. Attempt limits and validation, permission, authentication or schema errors affect the route, with terminal work offered review actions such as retry, hold and close.

A selected save failure can retain a completed description status. That gives the next decision useful information about what exists, without claiming that a repeated external operation is safe.

No concurrency test was run for this note. The optional image handoff also remains in the exports despite older README wording; it requires an explicit request and fails when its workflow isn't configured.