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

HOTFIX 2: mig 134 missing set_config('paliad.audit_reason', …) — paliad still offline after #130 #131

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

Incident

paliad.de still offline. After #130 (commit 6f8b4ea) fixed the 3-segment code-shape violation, a NEW error surfaces on mig 134:

migration failed: apply 134_berufung_unification.up.sql:
exec sql: pq: paliad.deadline_rules: audit reason required for UPDATE —
set paliad.audit_reason via SET LOCAL or set_config() (P0001)

Mig 134 UPDATEs paliad.deadline_rules (step 4d reassigns 16 rules to the unified upc.apl.unified proceeding type). The audit trigger added in mig 079 requires paliad.audit_reason to be set first.

Fix

Add the canonical set_config('paliad.audit_reason', …, true) call at the top of both mig 134 up + down SQL files. Pattern from mig 127, 099, 100, 106, 110, 129 etc. — well-established.

Files to edit

  1. internal/db/migrations/134_berufung_unification.up.sql — add at the very top, before any DO block / UPDATE: 
    SELECT set_config(
    'paliad.audit_reason',
    'mig 134: t-paliad-292 Slice B1 — Berufung unification, collapse 3 UPC appeal proceeding_types into upc.apl.unified + appeal_target discriminator',
    true);
  2. internal/db/migrations/134_berufung_unification.down.sql — same pattern, with a down-flavored reason string: 
    SELECT set_config(
    'paliad.audit_reason',
    'mig 134 DOWN: revert Slice B1 — restore 3 separate UPC appeal proceeding_types, drop applies_to_target column',
    true);

Acceptance

  1. grep -nE "set_config\\('paliad\\.audit_reason'" internal/db/migrations/134_berufung_unification.up.sql internal/db/migrations/134_berufung_unification.down.sql returns 2 hits (one per file).
  2. go build ./... clean (no real change to build).
  3. Commit pushed to main → Dokploy auto-deploys → mig 134 applies cleanly → paliad.de responds 200 or 302 (it's behind an auth gate, so 302 to /login is the healthy state).
  4. Comment on this issue with commit SHA + post-deploy container status.

Why

The paliad.audit_reason mechanism (added in mig 079) records why every deadline_rules mutation happened. Migrations that UPDATE the table must opt in via set_config. Cronus's mig 134 missed this — same root cause as #130 (didn't grep existing constraints/triggers before writing the migration).

Priority: prod still down.

## Incident paliad.de still offline. After [#130](https://mgit.msbls.de/m/paliad/issues/130) (commit `6f8b4ea`) fixed the 3-segment code-shape violation, a NEW error surfaces on mig 134: ``` migration failed: apply 134_berufung_unification.up.sql: exec sql: pq: paliad.deadline_rules: audit reason required for UPDATE — set paliad.audit_reason via SET LOCAL or set_config() (P0001) ``` Mig 134 UPDATEs `paliad.deadline_rules` (step 4d reassigns 16 rules to the unified `upc.apl.unified` proceeding type). The audit trigger added in mig 079 requires `paliad.audit_reason` to be set first. ## Fix Add the canonical `set_config('paliad.audit_reason', …, true)` call at the top of both mig 134 up + down SQL files. Pattern from mig 127, 099, 100, 106, 110, 129 etc. — well-established. ## Files to edit 1. `internal/db/migrations/134_berufung_unification.up.sql` — add at the very top, before any DO block / UPDATE: ```sql SELECT set_config( 'paliad.audit_reason', 'mig 134: t-paliad-292 Slice B1 — Berufung unification, collapse 3 UPC appeal proceeding_types into upc.apl.unified + appeal_target discriminator', true); ``` 2. `internal/db/migrations/134_berufung_unification.down.sql` — same pattern, with a down-flavored reason string: ```sql SELECT set_config( 'paliad.audit_reason', 'mig 134 DOWN: revert Slice B1 — restore 3 separate UPC appeal proceeding_types, drop applies_to_target column', true); ``` ## Acceptance 1. `grep -nE "set_config\\('paliad\\.audit_reason'" internal/db/migrations/134_berufung_unification.up.sql internal/db/migrations/134_berufung_unification.down.sql` returns 2 hits (one per file). 2. `go build ./...` clean (no real change to build). 3. Commit pushed to main → Dokploy auto-deploys → mig 134 applies cleanly → paliad.de responds 200 or 302 (it's behind an auth gate, so 302 to /login is the healthy state). 4. Comment on this issue with commit SHA + post-deploy container status. ## Why The `paliad.audit_reason` mechanism (added in mig 079) records *why* every deadline_rules mutation happened. Migrations that UPDATE the table must opt in via set_config. Cronus's mig 134 missed this — same root cause as #130 (didn't grep existing constraints/triggers before writing the migration). Priority: prod still down.
mAi self-assigned this 2026-05-26 13:13:06 +00:00
mAi commented 2026-07-29 14:36:53 +00:00
Author
Collaborator
Copy Link

Verified fixed — and the audit row it feeds was actually written

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

The set_config call exists in both files

134_berufung_unification.up.sql lines 33-36, under a -- 0. Audit reason header, before any DO block or UPDATE:

SELECT set_config(
    'paliad.audit_reason',
    'mig 134: t-paliad-292 Slice B1 — Berufung unification, collapse 3 UPC appeal proceeding_types into upc.apl.unified + appeal_target discriminator',
    true);

134_berufung_unification.down.sql lines 17-20 carries the down-flavoured twin, exactly as specified.

A note on acceptance 1, because it will mislead the next person

The acceptance criterion as written —

grep -nE "set_config\('paliad\.audit_reason'" …

returns zero hits, and the fix is correct anyway. The call is formatted across four lines, so set_config( and 'paliad.audit_reason' are never on the same line. I ran that exact grep first and it told me the fix was missing. A pattern that only matches the single-line form cannot verify a multi-line one. grep -n "paliad.audit_reason" on both files is the check that works.

The audit row was written — this is the part that proves it ran

The call existing proves the code is there; it does not prove the trigger was satisfied. On prod:

reason: "mig 134: t-paliad-292 Slice B1 — Berufung unification, collapse 3 UPC …"
rows:   32
first:  2026-05-26 13:21:27.4861+00

32 rows in paliad.deadline_rule_audit carrying mig 134's exact reason string, first written at 13:21:27.4861+00 — byte-identical to applied_migrations.applied_at for version 134. The UPDATE ran, the trigger passed, and the audit history records why.

What I could not verify

The post-deploy container status in acceptance 4. No shell on mlake. Prod is at migration head 211 and serving, so the outage is long over.

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

## Verified fixed — and the audit row it feeds was actually written **What I ran** — repo reads plus read-only queries against prod. ### The `set_config` call exists in both files `134_berufung_unification.up.sql` lines 33-36, under a `-- 0. Audit reason` header, before any DO block or UPDATE: ```sql SELECT set_config( 'paliad.audit_reason', 'mig 134: t-paliad-292 Slice B1 — Berufung unification, collapse 3 UPC appeal proceeding_types into upc.apl.unified + appeal_target discriminator', true); ``` `134_berufung_unification.down.sql` lines 17-20 carries the down-flavoured twin, exactly as specified. ### A note on acceptance 1, because it will mislead the next person The acceptance criterion as written — ``` grep -nE "set_config\('paliad\.audit_reason'" … ``` **returns zero hits, and the fix is correct anyway.** The call is formatted across four lines, so `set_config(` and `'paliad.audit_reason'` are never on the same line. I ran that exact grep first and it told me the fix was missing. A pattern that only matches the single-line form cannot verify a multi-line one. `grep -n "paliad.audit_reason"` on both files is the check that works. ### The audit row was written — this is the part that proves it ran The call existing proves the code is there; it does not prove the trigger was satisfied. On prod: ``` reason: "mig 134: t-paliad-292 Slice B1 — Berufung unification, collapse 3 UPC …" rows: 32 first: 2026-05-26 13:21:27.4861+00 ``` 32 rows in `paliad.deadline_rule_audit` carrying mig 134's exact reason string, first written at **13:21:27.4861+00** — byte-identical to `applied_migrations.applied_at` for version 134. The UPDATE ran, the trigger passed, and the audit history records why. ### What I could not verify The post-deploy container status in acceptance 4. No shell on mlake. Prod is at migration head 211 and serving, so the outage 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#131
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?