Module workflow_tasks 

Workflow-task dispatch endpoints (Phase 9).

A “workflow task” represents “this workflow has new events that need a worker to run the workflow handler against.” It’s distinct from an “activity task” (which runs concrete activity code). The dispatch loop:

1. The engine sets needs_dispatch=true on a workflow when something workflow-visible happens (started, activity completed, timer fired, signal arrived).
2. A worker calls POST /workflow-tasks/poll to claim the next dispatchable workflow on its queue. Response carries the workflow id, type, input, and full event history for replay.
3. The worker invokes the handler in a coroutine that yields commands (ScheduleActivity, CompleteWorkflow, FailWorkflow, etc.) instead of making side effects directly.
4. The worker POST /workflow-tasks/:id/commands to submit the batch. The engine processes each command transactionally and releases the worker’s claim on the workflow task.

Structs

PollWorkflowTaskRequest

SubmitCommandsRequest

Functions

poll_workflow_task

Claim a dispatchable workflow on the requested queue. Response is null when nothing is available (worker should sleep + retry).

router

submit_commands

Submit a batch of commands a worker produced from running the workflow handler. Each command is processed transactionally (ScheduleActivity inserts a row + appends ActivityScheduled, CompleteWorkflow flips the status + appends WorkflowCompleted, etc.) and the worker’s claim is released on success.