m/paliad
1
0
Fork 0
Code Issues 146 Pull Requests 8 Actions 1 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 · 0 comments
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
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?