Wait on a key
A run waits on a key that you choose. Your app wakes it by emitting an event with the same key:step.wait returns the event’s payload: here, the manager’s decision. If the event had no payload, step.wait returns null.
Choose the key
Build the key from what the run waits for, like the order it’s about. Your app can then emit the event from anywhere, without knowing the run’s ID:refund_${orderId}for the review of a refund.email_confirmed_${userId}for a confirmation link.export_done_${exportId}for another system’s job.
Make sure the run waits first
An event only wakes the runs already waiting on its key when it arrives. An event emitted before the run reaches its wait doesn’t wake it later. So trigger what you wait for in the step just before the wait, like the email that asks the manager for a review. The run is waiting long before anyone can answer.Several runs on the same key
An event wakes every run waiting on its key, not just one. To wake a single run, make the key unique to it, for example with the ID of what it works on.Wait more than once
A run can wait several times, on the same key or on different ones. Waits on the same key are matched in order, so a run that waits onreply_${ticketId} in a loop gets each reply in turn, as long as each one arrives while the run is waiting.
How long a run can wait
A run waits up to a year. After that, it fails withwaitExpired.
To give up sooner, start a second workflow that sleeps for the time you allow, then emits the event itself, with a payload that says the time ran out:
approved: false.