m/paliad
1
0
Fork 0
Code Issues 152 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

HOTFIX: mig 134 violates paliad_proceeding_code_shape (paliad.de offline, crash-loop) #130

New Issue
Open
opened 2026-05-26 13:05:32 +00:00 by mAi · 1 comment
mAi commented 2026-05-26 13:05:32 +00:00
Collaborator
Copy Link

Incident

paliad.de is offline. Container compose-transmit-multi-byte-driver-v7jth9-web-1 on mlake is crash-looping every ~65s since 2026-05-26 12:48 UTC, immediately after the Slice B1 deploy (commit 426b90b).

Diagnosis

internal/db/migrations/134_berufung_unification.up.sql line 89 attempts to insert code = 'upc.apl' into paliad.proceeding_types. The table carries this check constraint (pre-existing, unchanged):

CONSTRAINT paliad_proceeding_code_shape CHECK (
  (code ~ '^[a-z]+\.[a-z]+\.[a-z]+$') OR (code ~ '^_archived_')
)

upc.apl has only 2 dot-segments and fails the check. The whole migration TXN rolls back on every retry, so the DB is unchanged from pre-deploy state.

Fix

Rename the unified Berufung code from upc.apl to upc.apl.unified (3 segments, satisfies the constraint, preserves the design intent). The constraint stays as-is — it enforces a useful jurisdiction.category.specific shape across the catalog.

Files to edit

  1. internal/db/migrations/134_berufung_unification.up.sql — replace all 'upc.apl' string literals with 'upc.apl.unified' (lines 89, 123, 191, 224, 243, and any RAISE NOTICE messages that quote the literal — keep prose mentions readable). Check grep -n "'upc\.apl'" 134_berufung_unification.up.sql.
  2. internal/db/migrations/134_berufung_unification.down.sql line 47 — DELETE FROM paliad.proceeding_types WHERE code = 'upc.apl'; → use 'upc.apl.unified'.
  3. frontend/src/verfahrensablauf.tsx line 42 — { code: "upc.apl", ... } → "upc.apl.unified".
  4. frontend/src/client/verfahrensablauf.ts lines 67 and 81 — "upc.apl" → "upc.apl.unified".
  5. frontend/src/i18n-keys.ts line 1520 — "deadlines.upc.apl" → "deadlines.upc.apl.unified".
  6. frontend/src/client/i18n.ts — find both deadlines.upc.apl keys (DE + EN translation rows added by mig 134's frontend changes) and rename to deadlines.upc.apl.unified.
  7. pkg/litigationplanner/types.go line 185 — prose comment, can stay as upc.apl.unified for accuracy.

Do NOT change prose-only mentions in comments / docstrings that aren't string literals — they're descriptive.

Acceptance

  1. grep -n "'upc\.apl'\|\"upc\.apl\"" internal/ frontend/ pkg/ returns zero hits (only the 3-segment form remains).
  2. go build ./... and cd frontend && bun run build clean.
  3. go test ./... green.
  4. Commit pushed to main → Dokploy auto-deploys → mig 134 applies cleanly → paliad.de responds 200.
  5. Comment on this issue with the commit SHA + verification that the container is no longer restarting (ssh mlake "docker ps --filter name=compose-transmit-multi-byte" shows Up, not Restarting).

Why

The check constraint paliad_proceeding_code_shape is a long-standing invariant. Cronus's Slice B1 design assumed a 2-segment code without grepping the constraint first. The fix preserves both the constraint and the design intent.

Priority: production-down. No design choices to revisit — just rename and ship.

## Incident paliad.de is offline. Container `compose-transmit-multi-byte-driver-v7jth9-web-1` on mlake is crash-looping every ~65s since 2026-05-26 12:48 UTC, immediately after the Slice B1 deploy (commit `426b90b`). ## Diagnosis `internal/db/migrations/134_berufung_unification.up.sql` line 89 attempts to insert `code = 'upc.apl'` into `paliad.proceeding_types`. The table carries this check constraint (pre-existing, unchanged): ```sql CONSTRAINT paliad_proceeding_code_shape CHECK ( (code ~ '^[a-z]+\.[a-z]+\.[a-z]+$') OR (code ~ '^_archived_') ) ``` `upc.apl` has only 2 dot-segments and fails the check. The whole migration TXN rolls back on every retry, so the DB is unchanged from pre-deploy state. ## Fix Rename the unified Berufung code from `upc.apl` to `upc.apl.unified` (3 segments, satisfies the constraint, preserves the design intent). The constraint stays as-is — it enforces a useful jurisdiction.category.specific shape across the catalog. ## Files to edit 1. `internal/db/migrations/134_berufung_unification.up.sql` — replace all `'upc.apl'` string literals with `'upc.apl.unified'` (lines 89, 123, 191, 224, 243, and any RAISE NOTICE messages that quote the literal — keep prose mentions readable). Check `grep -n "'upc\.apl'" 134_berufung_unification.up.sql`. 2. `internal/db/migrations/134_berufung_unification.down.sql` line 47 — `DELETE FROM paliad.proceeding_types WHERE code = 'upc.apl';` → use `'upc.apl.unified'`. 3. `frontend/src/verfahrensablauf.tsx` line 42 — `{ code: "upc.apl", ... }` → `"upc.apl.unified"`. 4. `frontend/src/client/verfahrensablauf.ts` lines 67 and 81 — `"upc.apl"` → `"upc.apl.unified"`. 5. `frontend/src/i18n-keys.ts` line 1520 — `"deadlines.upc.apl"` → `"deadlines.upc.apl.unified"`. 6. `frontend/src/client/i18n.ts` — find both `deadlines.upc.apl` keys (DE + EN translation rows added by mig 134's frontend changes) and rename to `deadlines.upc.apl.unified`. 7. `pkg/litigationplanner/types.go` line 185 — prose comment, can stay as `upc.apl.unified` for accuracy. Do NOT change prose-only mentions in comments / docstrings that aren't string literals — they're descriptive. ## Acceptance 1. `grep -n "'upc\.apl'\|\"upc\.apl\"" internal/ frontend/ pkg/` returns zero hits (only the 3-segment form remains). 2. `go build ./...` and `cd frontend && bun run build` clean. 3. `go test ./...` green. 4. Commit pushed to main → Dokploy auto-deploys → mig 134 applies cleanly → paliad.de responds 200. 5. Comment on this issue with the commit SHA + verification that the container is no longer restarting (`ssh mlake "docker ps --filter name=compose-transmit-multi-byte"` shows Up, not Restarting). ## Why The check constraint `paliad_proceeding_code_shape` is a long-standing invariant. Cronus's Slice B1 design assumed a 2-segment code without grepping the constraint first. The fix preserves both the constraint and the design intent. Priority: production-down. No design choices to revisit — just rename and ship.
mAi self-assigned this 2026-05-26 13:05:32 +00:00
mAi commented 2026-07-29 14:36:37 +00:00
Author
Collaborator
Copy Link

Verified fixed in the migration, not stepped past

What I ran — repo greps plus read-only queries against prod.

The constraint violation is fixed in mig 134 itself

internal/db/migrations/134_berufung_unification.up.sql inserts 'upc.apl.unified' (line 99), and every other code literal in the file is 3-segment: lines 113, 133, 144, 158, 179, 187, 195. The rename was applied to the migration, not worked around downstream.

Acceptance 1 passes. grep -rnE "'upc\.apl'|\"upc\.apl\"" internal/ frontend/src/ pkg/ returns exactly one hit, and it is a prose comment in 155_upc_apl_resplit.up.sql describing a pre-flight check — not a string literal. The issue explicitly excluded prose mentions.

The constraint is intact and was never relaxed

paliad_proceeding_code_shape
  CHECK ((code ~ '^[a-z]+\.[a-z]+\.[a-z]+$') OR (code ~ '^_archived_'))

Unchanged on prod. upc.apl.unified satisfies it. The fix preserved the invariant, as the issue intended.

It applied cleanly on prod

version 134  berufung_unification  applied_at 2026-05-26 13:21:27.4861+00

The issue reports the crash-loop starting 12:48 UTC, so the outage ran roughly 33 minutes.

One thing worth knowing before closing

Mig 155 later reversed what mig 134 built, on m's own ruling (Q5, 2026-05-27: "Reverse the unification… they are actually different proceedings!"). Applied 2026-05-27 13:09:00. Current prod state:

id code active rules
11 upc.apl.merits yes 17
19 upc.apl.cost yes 3
20 upc.apl.order yes 14
160 upc.apl.unified no 0

So the hotfix is real and permanent — the code shape is still correct in the migration file and the constraint still holds — but the feature it unblocked no longer exists. That does not reopen anything; it just means nobody should go looking for upc.apl.unified in the product.

What I could not verify

The container-status half of acceptance 5 (ssh mlake docker ps). I have no shell on mlake. What I can say is that prod is at migration head 211 and serving, so the crash-loop is long over.

Verdict: resolved. Not closing — that is m's.

## Verified fixed in the migration, not stepped past **What I ran** — repo greps plus read-only queries against prod. ### The constraint violation is fixed in mig 134 itself `internal/db/migrations/134_berufung_unification.up.sql` inserts `'upc.apl.unified'` (line 99), and every other code literal in the file is 3-segment: lines 113, 133, 144, 158, 179, 187, 195. The rename was applied to the migration, not worked around downstream. **Acceptance 1 passes.** `grep -rnE "'upc\.apl'|\"upc\.apl\"" internal/ frontend/src/ pkg/` returns exactly one hit, and it is a prose comment in `155_upc_apl_resplit.up.sql` describing a pre-flight check — not a string literal. The issue explicitly excluded prose mentions. ### The constraint is intact and was never relaxed ``` paliad_proceeding_code_shape CHECK ((code ~ '^[a-z]+\.[a-z]+\.[a-z]+$') OR (code ~ '^_archived_')) ``` Unchanged on prod. `upc.apl.unified` satisfies it. The fix preserved the invariant, as the issue intended. ### It applied cleanly on prod ``` version 134 berufung_unification applied_at 2026-05-26 13:21:27.4861+00 ``` The issue reports the crash-loop starting 12:48 UTC, so the outage ran roughly 33 minutes. ### One thing worth knowing before closing **Mig 155 later reversed what mig 134 built**, on m's own ruling (Q5, 2026-05-27: *"Reverse the unification… they are actually different proceedings!"*). Applied 2026-05-27 13:09:00. Current prod state: | id | code | active | rules | |---|---|---|---| | 11 | `upc.apl.merits` | yes | 17 | | 19 | `upc.apl.cost` | yes | 3 | | 20 | `upc.apl.order` | yes | 14 | | 160 | `upc.apl.unified` | **no** | 0 | So the hotfix is real and permanent — the code shape is still correct in the migration file and the constraint still holds — but the feature it unblocked no longer exists. That does not reopen anything; it just means nobody should go looking for `upc.apl.unified` in the product. ### What I could not verify The container-status half of acceptance 5 (`ssh mlake docker ps`). I have no shell on mlake. What I can say is that prod is at migration head 211 and serving, so the crash-loop is long over. **Verdict: resolved.** Not closing — that is m's.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#130
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?