Files
buzz/migrations
npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67dandTyler Longwell 9e0534eecc fix(workflow): add scheduled_workflow_fires.workflow_run_id for the attach audit link
The scheduler's post-run `attach_scheduled_workflow_run` does `SET workflow_run_id`,
but neither schema/schema.sql nor the initial migration declared that column, so
every won scheduled claim would create+run, then the best-effort attach would hit
`column "workflow_run_id" does not exist` (PG 42703) and warn forever — the audit
link could never populate. Found by Max in cold review of 778a5d28c.

- Add nullable `workflow_run_id UUID` to scheduled_workflow_fires (schema + migration)
  with a composite FK `(community_id, workflow_run_id) REFERENCES workflow_runs
  (community_id, id)`. The FK uses ON DELETE NO ACTION, not SET NULL: community_id is
  shared with the claim PK and is NOT NULL, so SET NULL is unimplementable (verified
  against live PG: it raises a NOT NULL violation mid-cascade). NO ACTION blocks a
  delete of a still-linked run cleanly; workflow_runs are not pruned today regardless.
- Rewrite the stale scheduled-fires schema comment that still claimed community is
  'resolved server-side from workflow_id, never a caller-supplied claim parameter' —
  contradicted by the S1 reconciliation: community is server provenance from
  list_all_enabled_workflows(), passed explicitly, since id is not globally unique.
- Surface the interval-anchor read failure with a warn! instead of unwrap_or(None)
  swallowing it (still fail-closed: a missing anchor suppresses the tick and retries).
- Add attach_links_run_to_claim_and_is_idempotent: proves the column populates on
  attach and the IS NULL guard makes a second attach a no-op. Proven RED against the
  pre-migration schema (the exact 42703 error), GREEN after — the regression that
  would have caught this gap.

Verified vs live Postgres, serial: buzz-db 110 / buzz-workflow 145 / buzz-relay 414,
0 failed; clippy -D warnings clean on the trio.

Co-authored-by: Tyler Longwell <tlongwell@block.xyz>
Signed-off-by: Tyler Longwell <tlongwell@block.xyz>
2026-06-27 14:43:51 -04:00
..