fix: hold candidate traffic and workers until migration commit

2026-09-09 23:21:53 +02:00
parent a0c0ee26ca
commit be0fbaa53c
10 changed files with 236 additions and 2 deletions
@@ -17,3 +17,24 @@ brokerreceipt voordat de configuratie definitief wordt overgezet.

 De override is offline getest met echte Compose-rendering en ontbrekende
 invoervariabelen. Toevoeging van dit bestand bewijst geen uitgevoerde productiemigratie.
+# Outbound worker hold
+
+Before starting a migration candidate, create `.migration-worker-hold` in its
+cloned `/app/local` directory. The supervised Celery worker and scheduler wait
+without consuming tasks until the operator removes that exact attempt-owned
+file after the deployment commit. Normal startup is unchanged when it is absent.
+Do not put the marker into the original data. This is a startup gate, not a
+control for pausing an already-running worker. Recovery before commit retains
+the hold and candidate data; recovery after commit resumes activation and must
+never revert to stale original data after outbound work has been released.
+
+The first Django middleware also returns 503 (no-store) for every ordinary
+request while held, including GET requests. Only exact GET/HEAD requests to
+`/health/ready/` and `/health/live/` pass. Marker inspection errors fail closed.
+The migration helper creates a nonce-bound marker only in the cold clone and
+removes it with directory fsync after a durable `committed` journal. Recovery
+after that boundary may resume activation but can never restore old data.
+
+`MIGRATION_NETWORK` is required and must equal the inspected existing
+`vacatureradar_default` network. The managed Compose project does not move the
+application to a newly-created network.