Workflows

A workflow is the persistent definition of work that Chronoverse schedules. It contains a kind, a kind-specific payload, a minute interval, a failure threshold, and log-retention policy.

Workflow kinds

• HEARTBEAT performs a lightweight health check and never produces execution logs.
• CONTAINER runs a Docker image and command and may retain stdout and stderr.

Build lifecycle

Workflow execution inputs are prepared asynchronously by the workflow worker. Build states are QUEUED, STARTED, COMPLETED, FAILED, and CANCELED.

For CONTAINER workflows, build validates the user-authored payload and resolves the image reference/digest as workflow-level derived metadata. HEARTBEAT workflows leave resolved image fields empty. Jobs read the workflow metadata at execution time and never store image metadata themselves.

Generations and build hashes

Each relevant update advances the workflow generation. Events carry the generation they belong to, allowing workers and services to reject stale build, reschedule, termination, and deletion work.

Build hashes prevent repeated image and execution preparation when the effective user-authored execution inputs have not changed. Resolved image references and digests are outputs of build, not inputs to the build hash.

Termination and deletion

Termination stops future scheduling and coordinates active state changes. Deletion requires a terminated workflow with no incompatible active work. These checks are deliberate preconditions, not best-effort cleanup.

Mutation safety

Create and update requests require Idempotency-Key. Workflow state and its publication intent are committed together through the transactional outbox.