Compiled execution v2

The Runtime converts a Workflow definition into an executable artifact as part of publishing it. This gives the platform an opportunity to validate Node contracts, mappings, types, control flow, and trigger rules before the Workflow is activated improves performance by avoiding use of an interpreter at runtime.

From design to execution

The authoring and publish path has distinct stages:

The Console parses the YAML and checks its basic Workflow shape.
The platform resolves referenced Nodes, Methods, Connections, Sub-Workflows, and other contracts.
It validates Properties, Expressions, scopes, container shapes, placement, and trigger structure.
It generates and compiles the executable Workflow.
For Preview, it evaluates design-time samples where possible.
When a revision is published, the platform stores the compiled artifact and records it as the latest published revision for that Environment.
A published invocation loads that artifact and activates the Workflow with the selected trigger or runtime action.

Design-time compilation

The Workflow designer validates and compiles the current design after it has been idle briefly. This check can include unsaved changes.

Design-time compilation runs without publishing a revision. It supplies two types of feedback:

Diagnostics appear in the Problems tab.
Preview can materialize sample values for Expressions and mappings.

A Preview failure does not convert an otherwise successful compile into a compile failure. Preview depends on sufficient sample or inferred data, so a valid Workflow can have no useful preview result.

Debug also compiles an embedded copy of the current design. It can therefore run unsaved changes from the designer. Trigger publish checks that depend on the hosted runtime are not all applied in the same way during Debug.

Saving and publishing are separate

Saving a Workflow records its YAML source as a revision in version control. The revision has a FileHash, which identifies the saved content and protects updates from overwriting a newer version.

Publishing performs a full compilation for the target Environment and stores an executable artifact for that revision. The published record identifies the source FileHash, input and output contracts, Cluster placement, and trigger metadata needed at runtime.

The Console's save request also asks the platform to publish that revision. With Release Management enabled, it saves and publishes to the rank-0 Test Environment; promotion selects revisions for later Environments. Without Release Management, the same save-and-publish request applies across the Site's Environments. These remain separate platform operations even though the Console starts them together:

Save records source.
Publish creates and selects an executable artifact for an Environment.
Status controls whether the published Workflow can be activated there.

If saving succeeds but publish fails, the revision remains saved and the Console returns publish diagnostics. Correct the reported problem, then save again so the corrected revision can be published.

Published activation

HTTP, MCP, Schedule, listener, Run Now, and Sub-Workflow invocations use a published artifact. When an invocation asks for the latest revision, the runtime resolves the latest published record for that Workflow and Environment.

The runtime can cache loaded artifacts. Publishing a new revision updates the latest published record and invalidates the relevant published-Workflow lookup so later activations resolve the new artifact.

Designer Debug is different: it can compile and activate the definition supplied by the designer instead of loading the latest published artifact. This is why a successful Debug run does not prove that a revision has been saved, published, or enabled.

What compilation checks

Compilation builds on YAML and schema validation. It can report problems such as:

A Node, Method, Connection, or Sub-Workflow that cannot be resolved.
A missing, duplicate, or invalid Step name.
A Property that does not match the selected Method's scalar, object, array, or Stream contract.
An invalid reference, function, operator, or forward dependency.
A container Expression applied at an unsupported level.
A Step or Connection that cannot run on the selected Cluster.
Invalid trigger placement, routing, or response structure.
An embedded script that cannot be parsed, restored, or compiled.

An error blocks the affected compile or publish. A warning describes a condition that should be reviewed but does not necessarily prevent compilation.