DigitalOcean.Client write methods:
- create_droplet_snapshot/3 — POST a snapshot action (async)
- get_droplet_action/3 — poll action status
- list_droplet_snapshots/2 — snapshots for a droplet
- delete_snapshot/2 — DELETE (used by compensation)
All use the "provisioning" token purpose.
Steps.CreateDropletSnapshot — the first saga step that touches real
infra:
- execute: deterministic snapshot name (arcadia-snap-<droplet>-<saga8>);
checks context for a prior snapshot_id, then checks DO for a snapshot
already carrying that name (crash-between-post-and-save recovery),
then posts the action, polls to completion, finds the resulting
snapshot, records snapshot_id + snapshot_name in context.
- compensate: deletes the snapshot; treats HTTP 404 as success.
Provisioning.snapshot_droplet/2 — convenience saga starter.
Two DO eventual-consistency gotchas surfaced + handled:
- After a snapshot action reports "completed", the snapshot lags a few
seconds before appearing in /droplets/:id/snapshots. The step now
retries the lookup (find_snapshot_with_retry, 12x5s) instead of
failing with :snapshot_not_found_after_completion.
- Deletion has the same lag the other way — a deleted snapshot lingers
in the listing briefly. compensate just trusts the DELETE 2xx/404;
no post-delete verification needed.
Live smoke verified end-to-end against holyspiritbraypark.com:
[CreateDropletSnapshot, Fail] saga — the step created real snapshot
229305609, the Fail step triggered compensation, compensation deleted
the snapshot. Final: saga rolled_back, ledger
[create_droplet_snapshot: compensated, fail: failed], zero leftover on DO.
Test-harness note: smoke tests create sagas via Provisioning.create_saga
(no Oban enqueue) so a single manual Runner.perform/1 owns execution —
start_saga/1 enqueues an Oban job, and running both racing the same saga
corrupts the step ledger. Production only ever runs via Oban.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
