Background
The current Serverless Workflow DSL specification for Lifecycle Events defines an output attribute for both Workflow Completed and Task Completed events. This attribute is intended to carry the resulting data payload of the workflow or task execution.
The Problem
The CloudEvents specification (Size Limits section) explicitly states:
"Intermediaries MUST forward events of a size of 64 KiB or less."
Workflow and task outputs in production environments frequently exceed this 64KB threshold. Because lifecycle events act as the control plane for workflow orchestration, embedding large data payloads (the data plane) directly into these events introduces a significant risk. Generic event intermediaries, brokers, or API gateways routing these CloudEvents are well within their rights to drop or truncate events exceeding 64KB. This would lead to silent failures and broken integrations for downstream consumers waiting for state transitions.
Proposed Solution
To ensure strict interoperability with the CloudEvents spec and prevent systemic routing failures, I propose we remove the raw output attribute from the lifecycle events.
Instead of embedding the payload, we should recommend the Claim Check pattern.
Suggested Changes:
- Remove: The
output (map) property from the Workflow Completed Event and Task Completed Event.
- Introduce: An optional
outputReference or outputUri (URI) property (same for input-related events). This attribute would provide a standard URI pointing to the workflow engine's storage where the full output/input payload can be securely fetched by interested consumers.
Alternatives Considered
- Opt-in embedding: Allow users to explicitly configure whether the output is embedded via a workflow configuration flag, accompanied by strong documentation warnings about the 64KB limit.
- Truncated Summary: Introduce a strictly size-capped
outputSummary for lightweight status codes, while still removing the bulk data field.
Impact
This is a breaking change to the DSL schema. It will require updates to runtime implementations to ensure they emit the reference URI instead of the raw map. However, it is a necessary adjustment to guarantee architectural stability and adherence to standard eventing patterns.
References
Background
The current Serverless Workflow DSL specification for Lifecycle Events defines an
outputattribute for both Workflow Completed and Task Completed events. This attribute is intended to carry the resulting data payload of the workflow or task execution.The Problem
The CloudEvents specification (Size Limits section) explicitly states:
Workflow and task outputs in production environments frequently exceed this 64KB threshold. Because lifecycle events act as the control plane for workflow orchestration, embedding large data payloads (the data plane) directly into these events introduces a significant risk. Generic event intermediaries, brokers, or API gateways routing these CloudEvents are well within their rights to drop or truncate events exceeding 64KB. This would lead to silent failures and broken integrations for downstream consumers waiting for state transitions.
Proposed Solution
To ensure strict interoperability with the CloudEvents spec and prevent systemic routing failures, I propose we remove the raw
outputattribute from the lifecycle events.Instead of embedding the payload, we should recommend the Claim Check pattern.
Suggested Changes:
output(map) property from theWorkflow Completed EventandTask Completed Event.outputReferenceoroutputUri(URI) property (same forinput-related events). This attribute would provide a standard URI pointing to the workflow engine's storage where the full output/input payload can be securely fetched by interested consumers.Alternatives Considered
outputSummaryfor lightweight status codes, while still removing the bulk data field.Impact
This is a breaking change to the DSL schema. It will require updates to runtime implementations to ensure they emit the reference URI instead of the raw map. However, it is a necessary adjustment to guarantee architectural stability and adherence to standard eventing patterns.
References