Workflow validation v2

The Runtime validates a Workflow at several layers. The Console first checks the authored YAML and basic Workflow shape. The platform then validates runtime contracts and compiles the executable definition.

Diagnostics are shown in the designer's Problems tab. Builder MCP and assistant tooling can return the same diagnostic information as structured validation or compilation errors.

Diagnostic fields

Each diagnostic can contain:

Field Meaning
Severity Error blocks the relevant operation. Warning calls attention to a condition that can still be accepted.
Message Customer-readable description of the problem.
Code Stable category where one is available, such as FUNCTION_NOT_FOUND. YAML, schema, and rule checks use Y_, S_, and R_ prefixes in the Console. Compiler-originated codes can begin with CS.
Path The Workflow, Step, or Property location associated with the diagnostic. YAML parser errors use a line or line range.
Expected The required value shape, such as scalar, object, or collection, when the validator can provide one.

Use the code to understand the category and the path to find the authored value. The exact message provides the most specific correction.

Validation layers

YAML syntax

These errors mean the code view cannot be parsed as YAML. Common causes include invalid indentation, missing punctuation, or malformed quoted values.

YAML diagnostics use a Y_ code and a line location when available. Correct these first because the Console cannot reliably build the Workflow object until the document parses.

Workflow schema

Schema errors mean the YAML parsed, but its top-level or nested structure is not a valid Workflow definition. Examples include:

  • Steps is not an array.
  • Parameters or Returns is not a mapping.
  • A known field has the wrong basic type.
  • A Workflow or Step contains an unrecognized field.
  • A string-like field was interpreted as a YAML boolean or null because it was not quoted.

Schema diagnostics use an S_ code. They block the canvas from adopting the invalid code representation.

Designer rules

The Console adds warnings for conditions it can identify from the current design, including incompatible canvas connections and Workflow Return mappings that need review. These diagnostics use an R_ code.

Warnings do not make an otherwise valid Workflow object unparsable. Review them before relying on Preview, Debug, or publish.

Runtime contracts

The platform resolves the selected Node and Method definitions, then validates the Workflow against their contracts. It checks:

  • Required Parameters and Returns.
  • Scalar, object, array, and Stream shapes.
  • Nested Property definitions and unsupported complex literal values.
  • Connection existence, Connection type, Node version, and Cluster compatibility.
  • Sub-Workflow Parameters and Returns.
  • Container Step structure and scope.

Shape diagnostics can include Expected so you can distinguish, for example, a collection Expression from a scalar value.

Expressions and mappings

Expression validation covers:

  • Reference syntax and whether the referenced Step Return or Workflow Parameter exists.
  • Whether a nested Return Property is declared.
  • Forward references and out-of-scope references.
  • Supported operators and compatible operand types.
  • Function name, arity, and permitted placement.
  • Collection sources, predicates, and keys used by FILTER and GROUPBY.
  • The rule that Workflow Parameters cannot themselves use runtime Expressions.

See Expression syntax and Mapping functions for the supported language.

Triggers and publish

Trigger validation applies the receive/respond contract for HTTP and MCP Workflows and the configuration required by Schedule and listener triggers. It can reject:

  • More than one root trigger.
  • A missing, nested, or duplicate response Step where exactly one root response is required.
  • An unsupported HTTP Method or route.
  • Invalid Schedule or listener configuration.
  • A trigger that cannot be published for the selected Environment or Cluster.

Some hosted trigger checks are intentionally skipped in designer Debug.

Compilation

After contract validation, the Runtime generates and compiles the executable Workflow. Compilation diagnostics can expose an incompatible operator or another issue that only becomes apparent when all resolved types are combined.

The Console hides non-actionable compiler warnings whose codes begin with CS, but it retains compiler errors. Correct the Workflow-level cause described by the message rather than treating the generated implementation as editable source.

Resolve diagnostics efficiently

  1. Correct Y_ YAML errors so the document can be parsed.
  2. Correct S_ schema errors so the canvas and code view can synchronize.
  3. Resolve missing Nodes, Methods, Connections, and Sub-Workflow contracts.
  4. Correct shape, scope, mapping, and Expression errors from the innermost path outward.
  5. Review warnings and Preview results.
  6. Run the Workflow in Debug with representative inputs.
  7. Save and publish the intended revision, then confirm its status in the target Environment.

If a diagnostic has no path, search the definition for the names quoted in its message. If the problem follows a Node or Sub-Workflow contract change, refresh or recreate the affected Step so the designer can load the current Parameters and Returns.

See also

See Problems Pane for filtering and display behavior and Compiled Execution for the lifecycle around validation.