chesterdocs

#Wake waiting processes with a signal

A signal throw event wakes every process that is waiting at a catch event for the same signal, and hands them its payload; a signal nobody waits for is lost.

#How a signal travels

flowchart LR
  subgraph One["Process A"]
    T["Signal throw<br/>'Price list changed'"]
  end
  subgraph Two["Process B — waiting"]
    C1(("Signal catch"))
  end
  subgraph Three["Process C — waiting"]
    C2(("Signal catch"))
  end
  subgraph Four["Process D — not there yet"]
    C3(("Signal catch<br/>reached later"))
  end
  T -- "payload" --> C1
  T -- "payload" --> C2
  T -. "lost: nobody was waiting" .-> C3
  • A throw wakes every catch that is waiting for that signal at that moment — in any process, and in development and production deployments alike.
  • A catch that is reached after the signal was thrown keeps waiting for the next one. Signals are not stored.
  • The throwing process does not wait: it continues at once, whether anyone was woken or not.

#Where signals come from

A signal belongs to a system: it is an adapter of the Signal kind. The catch and throw events pick it by system and signal, not by the name in the diagram.

⚠️ The Designer's dialog for adding an adapter offers no signal kind, so a new signal cannot be created there. The Signal list only shows signals that already exist on a system.

#Configure a signal catch event

  1. System selection → System: pick a system linked to the process, or add one with + Add system….
  2. Signal: pick one of that system's signals.
  3. Signal details shows the Request Body Schema — the shape the signal's payload is meant to have. Later steps can pick these fields under the catch event's id.

#Configure a signal throw event

  1. System selection: pick the system and the signal, as for a catch.
  2. Signal payload: the data to send. It starts filled with the signal's schema; replace it with the values to send, using variables from earlier steps. The payload must work out to an object.

#What the events hand on

  • The catch files the payload it received under its own id — SignalCatch_price.newPriceList.
  • The throw files the payload it sent under its own id.

⚠️ The payload is not checked against the signal's schema. A catch receives whatever was sent, so a field the variable list offers may be missing at run time.

⚠️ The variable list shows the throw's fields only while its payload is plain JSON. Once it contains a variable, the list offers none.

#What signals cannot do

  • ⚠️ Stay within one process or one environment. A throw from a development deployment, or from a test run, wakes production processes waiting for the same signal too.
  • ⚠️ Guarantee a single broadcast. In rare cases, after an internal retry, a throw can be sent twice; a catch that is waiting again by then is woken again.
  • ⚠️ Default payload. If you leave the prefilled payload unchanged, the schema itself is sent as the data.
  • ⚠️ Checks before running. A mistake in the payload expression is not reported by validation; it fails the throw when the process runs.
  • ❌ Buffer a signal for a catch that is not waiting yet.
  • ❌ Start a process. A signal start event deploys, but no signal starts it — see Start a process.
  • ❌ End with a signal. A signal end event broadcasts nothing — see End a process. Put a signal throw event before a plain end event.
  • ❌ React on a task. Signal boundary events cannot be deployed.

#Wait for a signal or something else

Behind an event-based gateway, a signal catch can race a timer or a message: whichever happens first is taken. Validation warns when two paths of the same gateway wait for the same signal, because only one of them can be taken.

#What validation checks

Both events need a signal to be selected. The messages are shown in German. See Check that a process can run.