From 6bb1fe823a654acb7b659041ad0896e2f3ad3fa5 Mon Sep 17 00:00:00 2001 From: tegwick Date: Wed, 26 Aug 2026 01:10:58 +0200 Subject: [PATCH] =?UTF-8?q?feat(workplan):=20close=20STATE-WP-0083-T07=20?= =?UTF-8?q?=E2=80=94=20central=20reports=20schema=20ok=20at=20head?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit First execution failed in a way that proved the design: the pre-upgrade hook applied both migrations and deleted itself on success, then the k3s tunnel dropped before the API could roll. Schema was briefly ahead of code — the safe direction, and why additive migrations were the right shape. Records two gaps it exposed: a successful migration leaves no trace because of the hook delete policy, and bridge status reported a dropped tunnel as connected. Co-Authored-By: Claude Opus 5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2583210@bnt-lap001 Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006 --- ...-WP-0083-forge-derived-projection-reset.md | 33 ++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/workplans/STATE-WP-0083-forge-derived-projection-reset.md b/workplans/STATE-WP-0083-forge-derived-projection-reset.md index c172537..2056f35 100644 --- a/workplans/STATE-WP-0083-forge-derived-projection-reset.md +++ b/workplans/STATE-WP-0083-forge-derived-projection-reset.md @@ -220,7 +220,7 @@ manual inspection confirms. ```task id: STATE-WP-0083-T07 -status: todo +status: done priority: high ``` @@ -250,3 +250,34 @@ of defect as a projection that cannot name its source commit. Acceptance: central reaches `head`; `review_contracts` exists; the mechanism is declared in the chart; a mismatch between code and schema is reported rather than tolerated. + +**Done (2026-08-26).** Central reports +`schema: {status: ok, applied: d1a2b3c4e5f6, expected: d1a2b3c4e5f6}`. +`review_contracts` exists. Both pods run `main-97c8762`. + +The first execution is worth recording, because it failed in a way that proved +the design. The `pre-upgrade` hook ran, applied both migrations and deleted +itself on success — then the k3s API tunnel dropped (`unexpected EOF` → +`connection refused`) and Helm could not read the deployment to roll the API. +The release wedged at `pending-upgrade`; no pod rolled. + +The schema was therefore briefly *ahead* of the running code, which is the safe +direction and the reason additive migrations were the right shape: the old image +served correctly against the new schema throughout. A destructive migration in +the same circumstance would have taken the service down. + +Recovery was `helm rollback` to the last deployed revision — which clears the +wedge without touching the schema, there being nothing to undo — then re-running +the upgrade. The hook is idempotent, so the second run's `alembic upgrade head` +was a no-op. + +Two things this exposed, neither yet addressed: + +- The hook's `hook-succeeded` delete policy removes the Job on success, so a + *successful* migration leaves no trace. That made it look as though nothing had + run when in fact everything had. Retaining a short-lived record of successful + migrations, not only failed ones, would have answered the question immediately. +- `bridge status` reported `k3s-api-railiance01` as `connected` while holding a + stale pid, so its health signal did not reflect the dropped connection. A + tunnel monitor that cannot detect the failure it exists to detect is the same + defect class as a projection that cannot name its source commit.