Idempotency, checkpoints, and resuming

Unattended workflows get run twice. A retry after a timeout, a scheduler firing while the last run is still going, someone re-running it to see what it does. So the question isn't whether it happens — it's what the second run does.

Idempotent means running it again produces no additional change. The usual mechanism is checking before acting: does this issue already exist, has this file already been written, was this message already sent? A workflow that posts a summary should look for today's summary before posting one, and the check needs a stable identifier — a date, a run id, a content hash — rather than "something that looks similar".

Checkpoints make interruption survivable. Record what was attempted, what completed and what's pending, somewhere that outlives the process. A small JSON file is enough for a local workflow; the requirement is only that it's written as you go rather than at the end, since a run that dies before writing its state has left you nothing.

{
  "run_id": "2026-09-20-weekly",
  "completed": ["fetch_issues", "summarise"],
  "pending": ["post_summary"],
  "last_checkpoint": "2026-09-20T09:14:02Z"
}

Resuming then has two failure modes, and you have to test for both: repeating a completed side effect, and skipping pending work. Stop a run between steps, restart it, and confirm neither happened. The subtle case is a step that completed its action but died before recording it — which is exactly why the idempotency check matters. Checkpoints tell you where you probably are; the check before acting is what makes being wrong about that survivable.

Loading your workspace…