Skip to content

Commit 8a3a48c

Browse files
authored
Merge pull request #86 from cschleiden/document-signals
Document signals
2 parents 537dd65 + ff2fc66 commit 8a3a48c

File tree

1 file changed

+24
-0
lines changed

1 file changed

+24
-0
lines changed

README.md

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -324,6 +324,30 @@ t := workflow.ScheduleTimer(tctx, 2*time.Second)
324324
cancel()
325325
```
326326
327+
### Signals
328+
329+
Signals are a way to send a message to a workflow. You can send a signal to a workflow by calling `workflow.Signal` and listen to them by creating a `SignalChannel` via `NewSignalChannel`:
330+
331+
```go
332+
// From outside the workflow:
333+
c.SignalWorkflow(ctx, "<instance-id>", "signal-name", "value")
334+
335+
func Workflow(ctx workflow.Context) error {
336+
// ...
337+
338+
signalCh := workflow.NewSignalChannel[string](ctx, "signal-name")
339+
340+
// Pause workflow until signal is received
341+
workflow.Select(ctx,
342+
workflow.Receive(, func(ctx workflow.Context, r string, ok bool) {
343+
logger.Debug("Received signal:", r)
344+
}),
345+
)
346+
347+
// Continue execution
348+
}
349+
```
350+
327351
### Executing side effects
328352
329353
Sometimes scheduling an activity is too much overhead for a simple side effect. For those scenarios you can use `workflow.SideEffect`. You can pass a func which will be executed only once inline with its result being recorded in the history. Subsequent executions of the workflow will return the previously recorded result.

0 commit comments

Comments
 (0)