Enable postgres_changes broadcasts on shopping_items / shopping_lists and prove the path end-to-end with Vitest Realtime tests and a pgTAP configuration check. Infra changes that were silently blocking events - Migration 007: shopping_items + shopping_lists added to supabase_realtime publication with REPLICA IDENTITY FULL (UPDATE/DELETE payloads need the full row so list_id-based filters work and RLS can evaluate DELETE against OLD) - Realtime service: DB_USER=supabase_admin (superuser; supabase_replication_admin lacks CREATE on the `realtime` schema that the service auto-creates per tenant) - Realtime service: SELF_HOST_TENANT_NAME=realtime so the seed tenant name matches the default supabase-js resolves for localhost URLs (was realtime-dev → TenantNotFound) Tests - pgTAP 004_realtime_publication.sql — P-01..P-04: publication membership and REPLICA IDENTITY FULL for both shopping tables - Vitest realtime-postgres-changes.test.ts — R-01 INSERT broadcast, R-02 UPDATE carries full row, R-03 list_id filter isolates events - test-utils realtime-helpers.ts — subscribePostgresChanges() returns a waitFor(predicate, timeout) helper that captures the SUBSCRIBED handshake before returning so mutations issued right after are not lost - createClientAs now calls realtime.setAuth(token) so the server evaluates RLS against the test user's JWT - Justfile test-db now globs supabase/tests/*.sql so new pgTAP files are picked up automatically Totals: 54→57 Vitest, 12→16 pgTAP, 15 Playwright = 88 tests green. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
25 lines
1.2 KiB
SQL
25 lines
1.2 KiB
SQL
-- Migration 007: Realtime publication for shopping lists & items.
|
|
--
|
|
-- Supabase Realtime broadcasts Postgres changes through a logical-replication
|
|
-- publication named `supabase_realtime`. Tables not in the publication emit
|
|
-- no events, so nothing reaches subscribed clients.
|
|
--
|
|
-- REPLICA IDENTITY FULL makes UPDATE and DELETE events carry the entire row
|
|
-- (not just the primary key). We need this for two reasons:
|
|
-- 1) Clients filter events by `list_id` on shopping_items — a PK-only payload
|
|
-- on UPDATE/DELETE doesn't include list_id and the filter silently drops
|
|
-- valid events.
|
|
-- 2) Supabase Realtime evaluates RLS against the row being broadcast; for
|
|
-- DELETE events that means evaluating it against the OLD row, which is
|
|
-- only available with REPLICA IDENTITY FULL.
|
|
--
|
|
-- Cost: logical-replication WAL entries grow by ~1 row width per mutation.
|
|
-- For the shopping-lists workload (low write rate, small rows) the impact is
|
|
-- negligible.
|
|
|
|
ALTER PUBLICATION supabase_realtime ADD TABLE public.shopping_items;
|
|
ALTER PUBLICATION supabase_realtime ADD TABLE public.shopping_lists;
|
|
|
|
ALTER TABLE public.shopping_items REPLICA IDENTITY FULL;
|
|
ALTER TABLE public.shopping_lists REPLICA IDENTITY FULL;
|