You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 2.0/llms-full.txt
+174-3Lines changed: 174 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -721,7 +721,7 @@ Validation errors are returned in the standard control-plane error envelope with
721
721
722
722
# Signals
723
723
724
-
Signals allow you to trigger events in a workflow from outside the workflow. This can be useful for reacting to external events, enabling *human-in-the-loop* interventions, or for signaling the completion of an external task.
724
+
Signals allow you to trigger events in a workflow from outside the workflow. This can be useful for reacting to external events, enabling *human-in-the-loop* interventions, or for signaling the completion of an external task. For repeated ordered inputs with durable cursor advancement, use [Message Streams](./message-streams.md).
725
725
726
726
## Named Signal Waits
727
727
@@ -779,7 +779,7 @@ Signal behavior:
779
779
780
780
**Important:** The `await()` function should only be used in a workflow, not an activity.
781
781
782
-
For condition waits — waiting until a predicate over durable state becomes true — see [Condition Waits](./condition-waits.md). For a timeout-backed `await`, see [Signal + Timer](./signal+timer.md).
782
+
For condition waits — waiting until a predicate over durable state becomes true — see [Condition Waits](./condition-waits.md). For a timeout-backed `await`, see [Signal + Timer](./signal+timer.md). For repeated inbox/outbox flows, see [Message Streams](./message-streams.md).
783
783
784
784
# Queries
785
785
@@ -902,6 +902,145 @@ Those webhook routes accept the same JSON `arguments` field as Waterline, return
902
902
903
903
**Important:** Querying a workflow does not advance its execution, unlike signals.
904
904
905
+
# Message Streams
906
+
907
+
Message streams are the v2 authoring surface for repeated workflow messages:
908
+
human input loops, assistant replies, workflow-to-workflow notifications, and
909
+
other ordered messages that must survive replay and continue-as-new.
910
+
911
+
Workflow authors should use the first-class facade:
912
+
913
+
- `$this->inbox('stream-key')`
914
+
- `$this->outbox('stream-key')`
915
+
- `$this->messages('stream-key')`
916
+
- `Workflow\V2\MessageStream`
917
+
918
+
Do not write `workflow_messages` rows or cursor rows directly from application
919
+
workflow code. The facade is the stable contract; lower-level message services
920
+
exist for package/runtime integration.
921
+
922
+
## Receiving Messages
923
+
924
+
Use `peek()` when a workflow needs to inspect pending inbound messages without
925
+
advancing its durable cursor. Use `receive()` or `receiveOne()` when the
926
+
workflow is ready to consume messages and record cursor advancement in history.
927
+
928
+
```php
929
+
use Workflow\V2\Workflow;
930
+
931
+
final class ApprovalInboxWorkflow extends Workflow
The caller keeps addressing the workflow instance id. It does not need to know
1027
+
which run currently owns the stream cursor.
1028
+
1029
+
## Authoring Rules
1030
+
1031
+
- Use semantic stream keys such as `ai.assistant`, `human.replies`, or
1032
+
`approval.requests`; treat them as part of the workflow's public contract.
1033
+
- Use `peek()` for inspection and `receive()` / `receiveOne()` for durable
1034
+
consumption.
1035
+
- Use `sendReference()` for outbound messages; store large payloads in an
1036
+
application payload store and pass a reference.
1037
+
- Keep application code on `Workflow::inbox()`, `Workflow::outbox()`, and
1038
+
`MessageStream`; do not depend on `MessageService`, `WorkflowMessage`, or
1039
+
cursor-row writes as the authoring pattern.
1040
+
- For one-shot external events, use [Signals](./signals.md). For request/return
1041
+
state changes, use [Updates](./updates.md). Use message streams when repeated
1042
+
ordered messages need cursor semantics.
1043
+
905
1044
# Updates
906
1045
907
1046
Updates allow you to retrieve information about the current state of a workflow and mutate the workflow state at the same time. They are essentially both a query and a signal combined into one.
@@ -3314,7 +3453,7 @@ When a workflow continues as new, the new run inherits the previous run's metada
3314
3453
| Visibility labels | Carried forward as-is (set once at start time) |
3315
3454
| Business key | Carried forward as-is |
3316
3455
| Compatibility marker | Carried forward so the new run targets the same worker build |
3317
-
| Message cursor position | Carried forward so the new run knows which inbound messages (signals/updates) were already consumed |
3456
+
| Message cursor position | Carried forward so the new run knows which inbound messages were already consumed through [Message Streams](./message-streams.md) |
3318
3457
3319
3458
The new run starts with the inherited metadata and can continue upserting search attributes and memo from there. This means a long-lived polling workflow can accumulate metadata across generations without losing state when it sheds history.
3320
3459
@@ -3341,6 +3480,11 @@ class PollingWorkflow extends Workflow
3341
3480
}
3342
3481
```
3343
3482
3483
+
For long-lived human-input or assistant loops, prefer the first-class
facade. Pending stream messages and cursor position move to the continued run,
3486
+
while consumed messages remain on the original run as history evidence.
3487
+
3344
3488
# Versioning
3345
3489
3346
3490
Since workflows can run for long periods, sometimes months or even years, it's common to need to make changes to a workflow definition while executions are still in progress. Without versioning, modifying workflow code that affects the execution path would cause non-determinism errors during replay.
@@ -5422,6 +5566,27 @@ The export includes a SHA-256 integrity checksum. Set `DW_V2_HISTORY_EXPORT_SIGN
5422
5566
5423
5567
The exported `selected_run` block includes `waits_projection_source`, `timeline_projection_source`, `timers_projection_source`, and `lineage_projection_source`. The exported `links` block also includes `projection_source`, and the `links.parents` / `links.children` sections come from the selected run's typed lineage history first, so child-workflow and continue-as-new relationships remain visible in the bundle even if mutable link rows have drifted during a local experiment. When a lineage row is surviving only through older mutable compatibility data, the bundle now marks that entry with `history_authority = mutable_open_fallback` and `diagnostic_only = true` instead of silently rehydrating extra link metadata during export.
5424
5568
5569
+
## AI Workflow Message Streams
5570
+
5571
+
Repeated AI or human-input workflows should use the first-class v2 message
0 commit comments