~bigbes/sr-ht-spec

ref: 2dc6b71739a6101f0c113df5ae27d2007b52dbd9 sr-ht-spec/migrations/0003_webhooks.sql -rw-r--r-- 2.8 KiB
36976713 — Eugene Blikh 25 days ago
feat(db): webhook + user tables (Phase 5a foundation)

The DB foundation for GraphQL-native webhooks, matching the core-go /
pages.sr.ht convention:

- "user" table — spec is single-owner, but the webhook subscription is
  user-scoped in core-go's model, so a user row is the owner's identity
  and the FK target. Columns mirror core-go auth.LookupUser so the table
  is ready if the service ever adopts core-go auth; today only id/username
  are used (owner seeded at startup).
- webhook_event enum (PROPOSAL_OPENED/MERGED/REJECTED), auth_method enum.
- gql_user_wh_sub / gql_user_wh_delivery — column names match core-go's
  webhooks engine exactly (it selects/inserts by these names). The
  events check uses cardinality() not array_length() so an empty event
  list is rejected at the DB (array_length returns NULL there, which a
  CHECK does not reject — a latent gap in the upstream convention).

Webhook tables use bare `timestamp` (not spec's TIMESTAMPTZ) to match
core-go's `NOW() at time zone 'utc'` inserts. Verified: schema.sql and
the 0003 migration both apply and reverse cleanly; FK/check/cascade all
behave.