Durable Timers And Scheduling

A reminder handler must fire 24 hours after an event. The integrator schedules an OS cron or in-process setTimeout to call back.

Use ctx.sleep(24h) inside the durable handler: the invocation suspends and Restate resumes it via a durable timer after the delay, surviving restarts and redeploys with no external scheduler. An in-process timer dies with the process; a cron is a separate system to keep consistent. Keep the delay d…

A daily reconciliation must run every 24h forever. The integrator writes a workflow that ctx.sleep(24h) then recurses into itself by re-invoking by the same id.

Model recurrence as a self-rescheduling loop: each run does its work, then issues a delayed send to the NEXT run (a fresh id or a stepped id) — not a self-call with the same id (run-once would attach to the existing completed run, not start a new one). Keep each occurrence as its own invocation so …

An operator wants to enqueue a one-way invocation to run in 1 hour, without the caller awaiting it (fire-and-forget delayed send).

Use a delayed one-way send (ctx.send / invoke with a delay) so Restate schedules the target handler to start after the delay, durably and without the caller blocking. This is distinct from ctx.sleep (which suspends the current handler). Pick send-with-delay for decoupled scheduling, ctx.sleep for i…