feat(009): pin the Deployment to the stop-handler image (fifth pin) - #73
Conversation
The 2026-07-25 fail-loud run closed section 5's oldest acceptance item by finding a defect, and the fix could not reach the cluster without a rebuild. Digest 780eeefe (tag 7ff1347) is the first image whose entrypoint forwards container stop to rauthy, so hiqlite releases its WAL and state-machine locks and the next boot starts clean; until now every boot after every restart began unclean and could escalate into a crash loop from an ordinary kubectl delete pod. The same image carries spec 006's name-reuse fix: uniqueness scoped to non-removed rows, enforced fleet-wide, with a typed 409 ahead of the action gate. Its DROP CONSTRAINT was applied live ahead of the merge, so no ordering window exists and the production symptom is already fixed; what arrives with the image is the typed 409 and the plain idx_fleet_app_name that ensureSchema emits on first boot. No schema, secret, or env delta rides this pin. The digest change rolls the pod by itself under Recreate.
AI Code ReviewSpec CouplingThe amendment explicitly acknowledges that the entrypoint fix lives in "spec 002's territory" and the name-reuse fix in "spec 006's territory," but neither Acceptance Criteria Are ProspectiveThe three acceptance signals are written in future tense ("The rolled pod is No Other Issues
Automated review by Claude. Diff size: 68 lines. |
1 participant
What
Moves the Deployment from digest
43717a27to780eeefe(tag7ff1347, the PR #72 merge), and records the pin as spec 009's fifth-pin amendment.Why now
The 2026-07-25 fail-loud run closed section 5's oldest acceptance item, but it closed it by finding a defect:
docker/entrypoint.shis PID 1 and had no signal handler, so on every container stop rauthy was SIGKILLed and never released its hiqlite WAL and state-machine locks. Every boot after every restart began unclean, and intermittently the stale lock aborted rauthy into a crash loop, reachable from an ordinarykubectl delete pod.The fix landed in PR #70 (and enrahitu #31), but the running image predates it. This pin is what makes that work real in production.
What rides it
Two changes, from two specs' territory:
docker/entrypoint.sh):TERM/INTtraps forward the stop to rauthy and the app, then wait. Installed immediately after rauthy is backgrounded, so a stop during the rauthy health wait is handled too.backend/fleet/*):fleet_app.namekeeps its index and losesunique; uniqueness is scoped to non-removed rows, enforced fleet-wide, and deploy answers a typed 409 ahead of the action gate.Risk
Lower than a pin normally carries. The
DROP CONSTRAINTwas applied to the live database on 2026-07-25 ahead of the #69 merge (precedent: theportBIGINTALTER, third pin), so no ordering window exists, and since the deployed code has no name check at all that ALTER alone already fixed the production symptom. No schema delta, no secret delta, no env change. The digest change rolls the pod by itself underRecreate.Acceptance
Three signals, verified after Flux reconciles:
Readyon780eeefe, edge serves 200.kubectl delete podlogs[entrypoint] received SIGTERM; stopping supervised processes, and the replacement boots without theLockFile ... exists already - this is not a clean start!warnings every boot has carried until now. First time that absence is observable.fleet_appcarriesidx_fleet_app_name(ensureSchemaemits it only when the column is not unique, so it appears on this image's first boot, not on the boot after the ALTER).Local gate:
compile,index,lint --fail-on-warn,index check,coupleall green (couple: 2 paths, no drift).