Back to notes
The Tesseract MemoryTechnical note

A valid worker secret isn't ownership of a render job

Quiet Lineage assigns image-generation jobs to workers. A worker needs permission to call the service and a current claim on the job, while repeated requests also need a state check.

Published 2 min read
Topics

The dispatcher gives the worker a specific claim

Quiet Lineage's dispatcher decides which queued images can be rendered next. It checks capacity, sorts ready jobs by priority and age, and only claims a row that is still ready. Claiming increments the attempt and saves an execution token. The worker receives that token with the job, post and shot IDs and the generation prompt.

Payload parsing accepts an object or a JSON object string, but rejects arrays and other values. This gives the worker a defined request shape before it attempts to act on the claim.

Entry and updates answer different questions

The configured shared secret controls entry to the worker, with missing configuration treated as failure. The job ID and token then scope rendering and terminal updates to the claim supplied by the dispatcher. A valid service caller still needs that current claim.

Dispatch rollback adds a state check: the row must still be claimed under the same token. A late failure response therefore won't reset a row the worker has already moved into rendering.

A token can remain valid across two requests

The initial rendering update matches the job ID and token but doesn't require a status such as claimed. A second webhook carrying the same active token can reach that path again. This is a replay concern identified in the source, not an observed duplicate provider render.

The worker goes on to poll, check the download, save it to Drive, persist the asset, enqueue QA and record success. I'd repeat the handoff during those steps and simulate a lost response after acceptance. Each update needs both the right owner and a state that still permits the transition.

Claim ownership across dispatcher and worker

Service authentication protects entry; job ID and token scope state writes on both success and recovery paths.

Direct callAsync taskBlocked / denied
Queue ownership
Dispatch boundary
Worker completion

Scroll or drag the background to move. Use the zoom buttons to resize.Arrow keys move between components. Enter selects.

Choose a component to explore

Select a numbered component on the map or use the component menu. Its details and connections will appear here.

No component selected.

All connections (11)
  1. 01 · Job record → 02 · Capacity and orderingReady and in-flight rows · Direct call
  2. 02 · Capacity and ordering → 03 · Conditional claimCandidate jobs · Direct call
  3. 03 · Conditional claim → 01 · Job recordClaimed + token · Direct call
  4. 03 · Conditional claim → 04 · Authenticated webhookWebhook payload · Async task
  5. 04 · Authenticated webhook → 05 · Worker rendering transitionAuthenticated request · Direct call
  6. 05 · Worker rendering transition → 01 · Job recordToken-scoped rendering write · Direct call
  7. 05 · Worker rendering transition → 06 · Persist artifact and enqueue QAProvider result · Direct call
  8. 06 · Persist artifact and enqueue QA → 07 · Token-scoped terminal writeStored artifact + QA job · Direct call
  9. 07 · Token-scoped terminal write → 01 · Job recordTerminal state · Direct call
  10. 03 · Conditional claim → 08 · Dispatch-failure recoveryHandoff failure · Blocked / denied
  11. 08 · Dispatch-failure recovery → 01 · Job recordRestore owned claim · Direct call

Build context