From 92f6ba31b58f5f710595d01384cb555112f73c22 Mon Sep 17 00:00:00 2001 From: Dimitri Yatsenko Date: Wed, 1 Jul 2026 12:01:33 -0500 Subject: [PATCH] docs(deploy): note set_replica_identity is non-atomic on partial failure The spec omitted the failure mode: tables are altered one at a time, so a mid-run error leaves earlier ALTERs committed and returns no summary. Matches the behavior documented in deploy.py's docstring. Re-run to converge. --- src/reference/specs/deploy-operations.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/reference/specs/deploy-operations.md b/src/reference/specs/deploy-operations.md index b3d0cbcf..671ea0ca 100644 --- a/src/reference/specs/deploy-operations.md +++ b/src/reference/specs/deploy-operations.md @@ -68,6 +68,8 @@ Both `default` and `full` produce explicit `ALTER` statements. `default` is **no The underlying ALTER is metadata-only, instant, and idempotent at the PostgreSQL layer (re-applying the same mode is a no-op at the storage layer). +The operation is **not atomic**: tables are altered one at a time, so if execution raises on table _N_ of _M_, the first _N_−1 ALTERs have already committed and the exception propagates without returning a summary — re-run to converge (each ALTER is idempotent). + ## Design rationale Three structural decisions distinguish `dj.deploy` from alternatives that were considered and rejected. Each is informed by the failure modes the alternative would have produced.