Work Requests
See Work requests for a detailed overview.
Technically, scheduled Workflows are Work Requests with
children work requests (see the parent
field).
Work Requests have the following important properties:
task_type: the type of the task (
Worker
,Server
,Internal
, orWorkflow
; see Tasks)task_name: the name of the task to execute (used to figure out the Python class implementing the logic)
task_data: a JSON dict representing the input parameters for the task
status: the processing status of the work request. Allowed values are:
blocked: the task is not ready to be executed
pending: the task is ready to be executed and can be picked up by a worker
running: the task is currently being executed by a worker
aborted: the task has been cancelled/aborted
completed: the task has been completed
result: the processing result. Allowed values are:
success: the task completed and succeeded
failure: the task completed and failed
error: an unexpected error happened during execution
workspace: foreign key to the workspace where the task is executed
worker: foreign key to the assigned worker (is NULL while work request is pending or blocked)
unblock_strategy: specify how the work request can move from
blocked
topending
status. Supported values are:deps
: the work request can be unblocked once all the dependent work requests have completedmanual
: the work request must be manually unblocked
parent: workflow hierarchy tree (optional, NULL when scheduled outside of a workflow); foreign key to the containing WorkRequest. The parent hierarchy will eventually reach a top-level node of type
WORKFLOW
which is the node that manages thisWorkRequest
hierarchy, possibly including sub-workflows. See Workflows.dependencies: order of execution within a workflow hierarchy (optional, hierarchy is run in parallel unless otherwise constrained); ManyToMany relation with other
WorkRequest
(from the same workflow) that need to complete before this one can be unblocked (if using thedeps
unblock_strategy)workflow_data: JSON dict controlling some workflow specific behaviour; it is expected to support the following keys:
allow_failure
(optional, defaults to False): boolean indicating what to do with the parent workflow if the work request fails. If true, the workflow can continue, otherwise the workflow is interrupted.display_name
: name of the step in the visual representation of the workflowstep
: internal identifier used to differentiate multiple workflow callbacks inside a single workflow. It acts like a machine equivalent fordisplay_name
, to allow the orchestrator to encode the plan about what it is supposed to do at this point in the workflow.group
(optional): name of the group within this workflow containing this work request.
event_reactions: JSON dict describing actions to perform in response to specific events.
internal_collection: (only for workflow work requests): reference to a
debusine:workflow-internal
collection (see Category debusine:workflow-internal) that holds artifacts produced during this workflowexpiration_delay: retention time for this work request in the database
supersedes: optional work request that has been superseded by this one: this is used to track previous attempts when retrying tasks.
Blocked work requests using the deps
unblock strategy may have
dependencies on other work requests. Those are only used to control
the order of execution of work requests inside workflows: the
scheduler ignores blocked
work requests and only considers
pending
work requests. The deps
unblock strategy will change
the status of the work request to pending
when all its dependent
work requests have completed.