Checkpoint long work at side-effect boundaries

Minimal checkpoint state

Store the task identifier, next step, stable operation key and confirmed result references. Keep a distinction between planned, submitted, confirmed and unresolved. Do not store credentials or full copied evidence in the checkpoint by default.

Side-effect sequence

Persist the planned operation key before submission. Submit using that key if the service supports idempotency. Persist the returned receipt after confirmation. On restart, reconcile a submitted-but-unconfirmed operation through the service before repeating it.

Crash fixture

Stop the worker after the remote service commits but before the local confirmation is saved. The restarted worker should find the original remote operation by its key or status resource. If the service has no reconciliation mechanism, report the outcome as unknown and avoid automatically duplicating the effect.

Acceptance and limits

Test interruption before submission, during the request and after confirmation. The checkpoint should lead to a specific next action for each state. This is an original workflow protocol; a local checkpoint and a remote side effect are not one atomic transaction. Durable storage and idempotency retention must cover the expected restart interval.