fix(task): recover legacy worktree ownership cutover (#2463)

This commit is contained in:
Carlos Florêncio
2026-08-09 17:37:48 +01:00
committed by GitHub
parent d38d9a0b86
commit abc05be59e
10 changed files with 505 additions and 41 deletions
+6
View File
@@ -252,6 +252,12 @@ This release includes a one-time task-worktree ownership schema cutover (see [Op
- All writers stopped during the cutover — with PostgreSQL, do not run a mixed-version fleet across the upgrade; the cutover takes a database advisory lock and fails closed if it cannot serialize.
- One successful schema initializer: keep the deployment at a single replica during startup, and check `kubectl rollout status` before scaling out.
If the initializer reports a worktree-ownership conflict, stop the rollout and
do not delete database rows. The transaction leaves the legacy schema intact.
Restore service with a compatible pre-cutover image, or deploy the migration
hotfix and retry against the unchanged PVC. Do not run an older image against a
database after the cutover has committed.
`kubectl rollout undo` changes the image, not the database schema. After the cutover the final schema is intentionally not readable by older binaries, so a binary downgrade requires restoring the matching pre-upgrade database backup — do not start an older image against the normalized database. Reapplying the checked-in `k8s/deployment.yaml` without the image transformation resets the image to `kandev:latest`, so keep your production customization in your own overlay or deployment repository.
## Remove while retaining data