Send signal: <SignalName>
Description
Emits a signal to all subscriber pipelines. Each signal parameter maps to a typed input pin. When executed, one execution-intent row is enqueued for every subscribing pipeline; a NOTIFY wakes all cluster instances so any instance can claim and run a subscriber. Asynchronous by default; tick Wait for completion to block until every subscriber finishes and route to Error if any of them did not succeed.
When to use
Use Send signal whenever one pipeline needs to notify one or more other pipelines that something has happened — for example, after an order is placed, after a record is updated, or at the end of a long-running job. By default the sender does not wait for subscribers to finish; it enqueues intent rows and continues executing. Each subscriber pipeline runs independently, potentially on a different instance in the cluster.
Tick Wait for completion when the sending pipeline is orchestrating rather than merely announcing. The node then blocks until every subscriber run reaches a final state, and takes the Error pin if any of them ended as anything other than a clean completion — failed, timed out, cancelled, rejected by a plan limit, or blocked because the subscriber was halted. The log names which pipelines failed and how. A signal with no subscribers still succeeds: nothing was listening, so nothing failed.
Waiting has two limits worth knowing. A waiting sender stays RUNNING for the whole wait, and an execution is timed out after ten minutes, so Wait timeout (s) is capped at 540 seconds. And waiting turns a cycle into a deadlock, so a chain of waiting signals is refused past three deep — if you see that error, two pipelines are waiting on each other.
The Error pin also fires without waiting, for a signal that has been deleted or a payload that cannot be serialized.
The pins of the node are determined by the signal’s parameter list. Each named parameter appears as a labelled input pin, typed to the Model the parameter references. Wire your data values into those pins before the node executes.
Because dispatch goes through the execution-intent queue, the sender is resilient: if all subscribers are busy the intents sit in the queue until an instance claims them via SKIP LOCKED. With Wait for completion off there is no blocking or back-pressure on the sending pipeline at all.
Pins
Input pins
| Pin | Type | Default | Notes |
|---|---|---|---|
| Wait for completion | boolean | — | Off by default. When on, the node blocks until every subscriber run reaches a final state, then continues on Error if any of them did not complete cleanly. |
| Wait timeout (s) | integer | 300 | How long to wait before giving up and taking the Error pin. Capped at 540 seconds, because a waiting sender stays RUNNING and executions are timed out after ten minutes. Ignored while Wait for completion is off. |
Execution pins
| Pin | Direction |
|---|---|
| In | Input |
| Out | Output |
| Error | Output |
Example
A pipeline that processes an incoming order wires the completed Order model value
into the order input pin of Send signal: OrderPlaced, then continues with its
own confirmation email. Meanwhile, a separate pipeline triggered by
Receive signal: OrderPlaced runs asynchronously to update inventory — possibly on
a different instance — without slowing down the order-processing pipeline.
A nightly orchestration wants the opposite: it sends RebuildIndexes with Wait for completion ticked, so the report it generates afterwards only runs once every subscriber has rebuilt, and its Error pin catches a subscriber that failed.