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: docs/docs/guides/workflows.mdx
+160Lines changed: 160 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,6 +51,166 @@ service Example {
51
51
</TabItem>
52
52
</Tabs>
53
53
54
+
## Workflow Input
55
+
56
+
Every workflow definition generates a `<Workflow>WorkflowInput` struct that contains the workflow input and any registered signals. It is passed to the workflow constructor and should be embedded in the workflow struct to allow for query and update handlers to access the workflow input.
57
+
58
+
### Req
59
+
60
+
If the workflow specifies a non-empty input message type, the generated `<Workflow>WorkflowInput` struct will include a `Req` field that contains a reference to the workflow input.
If the workflow definition specifies one or more signals, the generated `<Workflow>WorkflowInput` struct will include a corresponding`{Signal}` field for each registered signalthat contains a reference to the [typed signal value](/docs/guides/signals).
The generated `<Workflow>WorkflowInput` struct includes a `ContinueAsNew` method that returns an appropriately configured `ContinueAsNewError`. This method is used to continue a workflow as a new workflow execution.
Every `<Workflow>Workflow` interface includes an `Execute` method that defines the workflow entrypoint. The signature of this method varies based on whether or not the workflow specifies a non-empty output message type.
0 commit comments