Coordinating render workers through to stored assets.

THE WORK

The project.

Quiet Lineage splits render coordination from the work of producing and storing each shot. An n8n dispatcher calculates available capacity, orders ready jobs by priority and age, and sends a claimed job to a separate worker with its execution token. The worker carries that token through consequential job updates, keeping a stable job ID from becoming permission to change any version of the job.

A provider completion is only the start of the finishing path. The worker checks the downloaded binary, stores it in Drive, creates the asset record and enqueues QA before recording render success. The exported implementation makes that sequence explicit, while leaving replay and partial-failure cases to test. In particular, the initial rendering update checks the token but not the job's current status.

IMPLEMENTATION

Design choices.

1. Ownership travels across the dispatcher-worker split. Repeating the claim token on job writes makes the current execution part of the update condition; knowing the stable ID or receiving a webhook response isn't enough by itself.
2. Service access and record ownership are checked separately. The shared secret admits the caller, while the job/token pair identifies the claim it may act on. Neither removes the need to check whether the current state still permits that action.
3. Rollback is narrower than a general reset. It releases only a still-claimed row under the same token, avoiding a late dispatch error resetting work that the worker has already advanced.
4. Success waits until the output is saved, registered and handed to QA. That gives success a concrete meaning, but the separate Drive and table operations still need recovery when only part of the sequence completes.

HOW IT FITS TOGETHER

Architecture.

• The dispatcher reads ready and in-flight jobs and subtracts current work from capacity. It orders eligible jobs by priority and age, then updates a matching ready job to claimed with an incremented attempt and the execution's lock token.
• The worker handoff includes job, post and shot IDs, the prompt and the claim token. Payload parsing accepts an object or JSON object string and rejects other shapes before dispatch.
• The worker checks its configured shared secret and validates the handoff before provider polling. Rendering and terminal updates match the job ID and token, although the initial rendering update doesn't yet require an expected current status.
• After completion, binary validation precedes Drive storage, asset persistence and QA enqueueing. The job becomes successful and its lock fields are cleared only after those steps, distinguishing a provider response from a stored asset ready for review.
• If dispatch fails, rollback requires the same job to remain claimed under the same token. It returns that row to ready without unconditionally undoing a state the worker may already have advanced.

ACCESS & INPUT

Security controls.

• The worker compares the supplied shared secret with its configured value and fails when configuration is missing. This checks service entry separately from permission to update a particular job.
• Consequential job updates include the job ID and lock token. Dispatch recovery also requires claimed state, so a late failure response won't match a job that has already moved on.
• The first rendering update lacks a current-status condition. A repeated request with a still-valid token therefore needs another check before the token can be treated as protection against replay.

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

1. Code and development records reviewedReviewed11 September 2026

   The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

   Scope of this check

   Code review, not a fresh run of the app