Skip to content

Migration hygiene follow-ups from #363 review #364

Description

@glassBead-tc

Greptile review of #363 raised three points. #363 merges as-is because its files are verbatim restorations of SQL already applied to prod under those ledger versions — editing them would recreate the file↔ledger divergence the PR repairs. Follow-ups:

  1. INSERT-only trg_set_workspace_id trigger (20260608000001): the trigger backfills workspace_id on child-table INSERT only. If protocol_sessions.workspace_id is ever updated or a child row re-parented, child workspace_id silently keeps the old value. Decide: intentional set-on-insert-only design (document it) or add a BEFORE UPDATE trigger via a new migration.

  2. Idempotency-guard discipline for future migrations: 20260608000001's FK constraints and CREATE TRIGGER statements have no guards (PG <17 has no ADD CONSTRAINT IF NOT EXISTS; CREATE TRIGGER has no IF NOT EXISTS). A partial-failure retry would fail on the first duplicate. Adopt the DO-block/exception-guard pattern for constraint+trigger DDL in future migrations. No action on already-applied files.

  3. Stale comment in 20260602214044: its header says the ulysses constraint values 'were applied directly to prod and staging but never captured as a migration' — no longer accurate now that 20260513090000 is on main. Fix the comment next time that area is touched (also note the two files recreate the same 6-value constraint; fresh builds run both, harmlessly).

Context: SPEC-V1-INITIATIVE Phase 0.2 (prod migration-ledger repair). Review source: #363

🤖 Generated with Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestjavascriptPull requests that update javascript code

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions