WORKFLOW_FAILED — workflow processor returned an error
cyoda-go version 0.8.4
errors.WORKFLOW_FAILED
Section titled “errors.WORKFLOW_FAILED”WORKFLOW_FAILED — a workflow processor or guard condition returned a failure during entity state transition, or returned data the model rejects.
SYNOPSIS
Section titled “SYNOPSIS”HTTP: 400 Bad Request. Retryable: no.
DESCRIPTION
Section titled “DESCRIPTION”During an entity create or transition operation the associated workflow processors (pre-processors, post-processors) or guard conditions ran but one of them signalled failure. The failure message from the processor is included in the error detail.
Three further causes are not processor failures at all, and reach the read endpoints GET /entity/{entityId}/transitions and GET /platform-api/entity/fetch/transitions as well as the write paths:
- The workflow selected for the entity does not declare its current state. Selection is by criterion and is re-evaluated on every call, so a data change can bind an entity to a definition that does not model the state it is parked in. The engine rejects rather than falling through to another definition that happens to declare it.
- A workflow selection criterion could not be evaluated. Where the cause is an unavailable compute member the error is
NO_COMPUTE_MEMBER_FOR_TAG(503, retryable) instead. - A transition or workflow criterion cannot be evaluated. Import validates a criterion’s path grammar, operator names, and pattern operands, but not against the model — a model may legitimately be declared after the workflow that references it. If, when the criterion is evaluated, it names a field the model still does not declare, or names an operator nobody recognises, or carries an operand a declared type cannot satisfy, the save that triggered the evaluation is aborted and rolled back — no entity write, no state transition, no partial effect. This applies to every operator, including a
NOTgroup’s child leaf. Seedocs/cloud-parity/unevaluable-criterion-fails-save.md.
Not retryable unless the underlying condition has changed. The failure originates from application logic in the processor, or from the workflow configuration; the data, the processor implementation, or the workflow configuration determines the outcome.
SEE ALSO
Section titled “SEE ALSO”- errors
- errors.WORKFLOW_NOT_FOUND
- errors.TRANSITION_NOT_FOUND
See also
Section titled “See also”cyoda help errors— Every error response from the Cyoda REST API carries a structurederrorCodein thepropertiesobject. Multiple codes may share the same HTTP status. Programmatic handling keys onerrorCode, not HTTP status.cyoda help errors WORKFLOW_NOT_FOUND— Entity models reference a workflow by name to govern state transitions. This error is returned when the named workflow cannot be found in the tenant’s workflow registry, during entity type registration or when a model references a workflow that was deleted.cyoda help errors TRANSITION_NOT_FOUND— Entity workflow state machines define explicit transitions between states. This error fires when a transition is triggered that does not exist in the model’s workflow definition for the entity’s current state. Also occurs when the transition name is misspelled, when the transition is disabled, when it is a scheduled transition (those fire on their timer and are never manually fireable), or when the entity is in a terminal state that allows no further transitions.cyoda help errors NO_COMPUTE_MEMBER_FOR_TAG— Workflow processors are dispatched to nodes that advertise matching compute tags. When no node with the required tag is alive in the cluster within the configured wait timeout (CYODA_DISPATCH_WAIT_TIMEOUT), the operation is rejected with this error.
Raw formats
Section titled “Raw formats”/help/errors/workflow_failed.json— full descriptor (matchesGET /help/{topic}envelope)/help/errors/workflow_failed.md— body only