Long-running coordination

A process that waits for several things over time, such as an order waiting for both payment and stock, needs no workflow language. Keep its progress in an ordinary entity, let each subscriber record one step on it, and let a schedule handle deadlines.

Here record_payment sets paid_at on the order. If stock is already reserved, it also sets the order's status to ready and emits OrderReady. cancel_expired_orders cancels orders left unpaid too long:

// domains/ordering/subscribers/on_payment_succeeded.jadposubscriber on_payment_succeeded {    on: PaymentSucceeded    run: record_payment(event.order_id)}// domains/ordering/actions/record_payment.jadpoaction record_payment(order_id: Order.id) fails OrderNotFound -> Unit {    ...}// domains/ordering/schedules/cancel_unpaid_orders.jadposchedule cancel_unpaid_orders {    every: 5m    run: cancel_expired_orders()}

The state is in the database, so it survives restarts and deploys, and you can query it and show it in an admin screen. Two steps arriving together can't both complete the order, because every write checks whether the record changed since it was read (All-or-nothing actions).