Worker protocol
Job states, capability tuples, leases, receipts, and workload isolation.
Heavy rendering runs asynchronously through an explicit worker protocol. The API queues jobs; workers claim, execute, and receipt them.
Job states
queued → running → finalizing → completed
↘ failed | interrupted | cancelling → cancelled| State | Meaning |
|---|---|
queued | Accepted, waiting for a capable worker |
running | Claimed by a worker holding a heartbeat lease |
finalizing | Outputs being registered, manifests written |
completed | Outputs available for authenticated download |
failed | Terminal failure with a reason |
interrupted | Worker lost its lease (crash or timeout) |
cancelled / cancelling | Explicit cancellation path |
Claiming and leases
Workers declare capability tuples — the job types they can execute. The
runtime continuously polls and claims matching jobs. While running, a worker
maintains a heartbeat lease: if the lease lapses, the job returns to the
queue (or lands in interrupted), never silently lost.
Workload isolation
The two workload kinds run in separate child-process pools:
| Workload | Pool | Produces |
|---|---|---|
chart.export.v1 | chart-worker | PNG, SVG, JSON, CSV |
motion.render.v1 | artifact-worker | PNG frames, MP4 |
Isolation guarantees that a long motion render cannot starve chart exports, and vice versa.
Receipts and provenance
On completion, the worker issues an output receipt and registers the resulting files with rendering provenance: the revision rendered, the data capture used, and the job that produced them. Consumers can therefore audit any downloaded output back to its exact inputs. See exports for the user-facing view.