ablative docs
↑↓ move↵ openesc close
Stack Notebook ablative.com.au

Signals, schedules and waits

Distinguish a durable wait inside a run from a schedule that starts new runs.

Open .md

Signals

An AWL workflow declares the signals it receives. A wait consumes a named signal with its declared payload type. Sending the same signal twice records two deliveries. Deduplicate repeat sends in the application when needed.

A send declaration describes a signal sent to another workflow. The target is a workflow id, or the declared child target form. The declaration and the receive contract are separate.

Timers and waits

Sleep uses a durable timer. A timed wait needs a timeout path as well as its received-value path. An ordinary child call waits for its result; spawn starts without waiting and cannot bind a result.

A workflow deadline ends the run. A timeout passed to the one-motion run command only bounds the client’s wait. These have different effects.

Schedules

Schedules have interval or cron triggers. They also declare what to do when runs overlap and when ticks were missed. Their owning namespace is fixed at creation.

There is no schedule CLI subcommand in the current command tree. Use the HTTP or gRPC schedule API. See schedule operations for the complete route set and an example.

Workloops

A workloop keeps one continuing identity, carried values and declared health checks. It closes an iteration by routing to start. A schedule starts a separate workflow execution at each firing.

Read AWL waits and workloops.