crewship signal
A routinewait step of kind: event parks its run durably until a named
event arrives. crewship signal delivers that event by topic: every run in
the workspace waiting on the event_type wakes at once, each receiving the
payload as its wait step’s output.
Which command do I want?
The two are the same act addressed differently. Reach for the topic form
whenever the sender is announcing something rather than answering a
specific run — that is the normal position for anything emitting events, and
it is the only form that works when several routines subscribe to one event.
crewship signal send
Deliver an event to every run in the workspace parked on it.
Backed by
POST /api/v1/workspaces/{ws}/signals. Requires MANAGER+, the same
tier as the per-run signal.
Output — the runs it woke, so you can follow them:
delivered to 0 runs (nothing is waiting on that event) and exits 0. An event
source emits whether or not a routine happens to be listening; treating that as
a failure would teach every caller to ignore the exit code.
Guarantees
- Workspace-fenced. A topic delivery never reaches a run in another
workspace. The workspace is the one your CLI session is scoped to
(
crewship workspace). - Claimed once. Each parked wait is claimed by exactly one delivery, so two people (or two producers) sending the same event at the same instant wake disjoint sets of runs — no run resumes its wait step twice.
- Durable. Delivery is recorded before the run is resumed, so a signal landing while the server restarts is not lost: the parked run reads it back at boot. See Durability and restart recovery.
See also
waitstep — authoring the step that parkscrewship routine signal— the per-run form- Routines API — the endpoint behind this command