postgres_changes INSERT/UPDATE not delivered to client despite SUBSCRIBED channel and valid RLS

[lucianovieir]

Project ref: eaksrtkvarlfhfjtzuam
Table: public.projects
Publication: supabase_realtime
Client libs: @supabase/ssr@0.10.3, @supabase/supabase-js@2.106.0
Framework: Next.js 16.2.6 (App Router, Turbopack)

Symptom

Channel subscribes successfully (status: SUBSCRIBED), heartbeats (phx_reply) arrive normally every ~15–30s, but zero postgres_changes messages are ever received for INSERT/UPDATE/DELETE on projects — including rows whose user_id exactly matches the connected user's auth.uid(), which RLS should (and does) permit for a normal SELECT.

Confirmed by watching the raw WebSocket Messages panel live in DevTools while inserting a row from another tab: only heartbeats appear, no postgres_changes frame arrives at all.

Reproduced in

• Desktop Chrome, normal window
• Desktop Chrome, Incognito window
• Mobile browser, entirely different network (cellular, not the same LAN/ISP as desktop)

All three show the identical symptom, ruling out browser profile, extensions, and local network as causes.

Environment

Client construction	createBrowserClient(url, anonKey) — module-scope singleton, confirmed single instance via a runtime instance-ID log across every component on the page
RLS on projects	enabled; SELECT scoped to user_id = auth.uid() (confirmed working correctly for plain REST reads and for direct Realtime tests, see below)
Channel	supabase.channel("kanban-realtime").on("postgres_changes", { event: "INSERT", schema: "public", table: "projects" }, ...).subscribe()

Hypotheses tested and ruled out

1. RLS blocking the row from its own owner — ✅ Ruled out
Method: authenticated as the real user via a server-generated session; subscribed to the channel; inserted a row via service_role with a matching user_id → event delivered. Repeated with a different user_id → correctly not delivered. RLS is filtering exactly as designed in both directions.

2. Multiple client instances / bundler chunk duplication of the singleton — ✅ Ruled out
Method: added a random instance ID logged at module load and at every createClient() call. Confirmed live in the browser: one instance ID, reused by every consumer on the page (Kanban board + four Sidebar badge components).

3. Insert mechanism (Server Action / RPC vs raw insert) — ✅ Ruled out
Method: subscribed as the real user, then inserted via (a) the app's actual authenticated-client .insert() call — the same code path the real "create project" Server Action uses — and (b) the app's real SECURITY DEFINER RPC function that creates a project from an approved quote. Both delivered the event correctly in isolation.

4. @supabase/ssr's createBrowserClient vs plain supabase-js — ✅ Ruled out
Method: reproduced using the actual createBrowserClient() (not the vanilla client), with its default document.cookie-backed storage (not a custom cookie jar), subscribing immediately after construction with no getSession() await — matching the app's exact production code sequence. Event still delivered.

5. INITIAL_SESSION not wired to realtime.setAuth() — ⚠️ Inconclusive lead
In @supabase/supabase-js's SupabaseClient._handleTokenChanged, only TOKEN_REFRESHED and SIGNED_IN trigger realtime.setAuth(token) — INITIAL_SESSION (fired when a page loads with an already-existing cookie session, the normal case here) is not handled. This looked like a strong candidate for a race between channel subscription and auth propagation, but simulating this exact code path directly did not reproduce the failure — the event still arrived. Flagging it regardless since it's a real gap in the SDK worth knowing about.

6. Realtime concurrent connection quota — ✅ Ruled out
Free plan allows 200 concurrent connections; only ~4 were open in the affected browser tab at any point observed.

7. Stale/leaked WebSocket connections competing for the topic — ⚠️ Investigated, unresolved
DevTools showed up to 4 simultaneous realtime WebSocket connections (ages 0 to ~8 minutes) in one tab. React cleanup (supabase.removeChannel(channel)) is present and correct in every consuming component. Checked the installed realtime-js source: _remove() correctly filters the internal channel array by topic, so the specific historical bug this resembles (supabase/supabase#4451) appears already fixed in this version. Per Phoenix Channels' pub/sub model, each independently joined connection to a topic should receive its own broadcast regardless of other connections existing — so this is suspected to be accumulated leftover connections from a long manual test session rather than an active per-navigation leak, but this was not conclusively confirmed.

What is confirmed working, every time, via direct script against the live project

• ✅ Fresh login (magic-link / OTP verified session) → INSERT for own row delivered
• ✅ Session restored purely from a cookie (no live login call) → INSERT for own row delivered
• ✅ Insert via the app's real authenticated Server Action code path → delivered
• ✅ Insert via the app's real SECURITY DEFINER RPC → delivered
• ✅ Different-owner row → correctly withheld

Every mechanism reachable from a Node script, against the same live project, behaves correctly. The failure is only observed in the real browser bundle, across three independent browsers/devices/networks.

What we're asking

Could someone check server-side Realtime logs for connections from project eaksrtkvarlfhfjtzuam at the reproduction timestamp(s) below, and confirm:

1. Was the INSERT on public.projects actually broadcast to the topic at that time?
2. Was our connection joined to that topic at the time of broadcast, and if so, why would the message not have reached the client?
3. If it was withheld by the RLS/authorization check specifically for our connection, what did that check evaluate (i.e. what JWT/role did it see for that socket)?

Reproduction timestamp(s)

channel/topic: realtime:public:projects (or exact string from the phx_join payload)
timestamp(s):
auth.uid(): 7048aa0c-60f0-4c82-985e-7dc1b4f2badd

[GaryAustin1]

Check with a simulated user in the realtime tab of the dashboard. If that works then the issue is in your client code (maybe not setting the session in the client before it subscribes). The inspector runs in your browser so also eliminates network type issues.

[harrysun2006]

Since Realtime enforces RLS on postgres_changes, the usual cause of "SUBSCRIBED + heartbeats fine but zero change events" is that the socket is connected anonymously — with @supabase/ssr the browser client often doesn't have the user's access token attached, so RLS silently drops every event.

Things to check, in order:

1. Set the auth token on the realtime client after sign-in (and again on token refresh):

   supabase.realtime.setAuth(session.access_token)

   And make sure you subscribe from the browser client that holds the session — not a server component.
2. REPLICA IDENTITY FULL on the table (needed for UPDATE/DELETE payloads and for RLS to evaluate the row):

   alter table public.projects replica identity full;

3. Publication includes the table for the ops you want:

   alter publication supabase_realtime add table public.projects;

4. Confirm Realtime is enabled for the table in Database → Replication.

In practice the vast majority of these reports come down to #1. Hope this helps!

[lucianovieir]

Found the root cause, and it was suggested by @harrysun2006 above — thank you!

The projects table had REPLICA IDENTITY set to default instead of FULL:

SELECT relreplident FROM pg_class WHERE relname = 'projects';
-- returned 'd' (default), not 'f' (FULL)

After running:

ALTER TABLE public.projects REPLICA IDENTITY FULL;

INSERT and UPDATE events started arriving correctly on the client with the full row payload. Everything else we tested (RLS policies, client singleton, @supabase/ssr vs vanilla client, hydration mismatches) was actually fine — REPLICA IDENTITY was the real blocker all along.

For anyone hitting the same symptom (channel status SUBSCRIBED, heartbeat working, but postgres_changes events never arriving despite correct RLS and a healthy connection): check REPLICA IDENTITY on the table first.

Also tried adding an explicit realtime.setAuth(token) call on every auth state change (including INITIAL_SESSION) as defense-in-depth, but couldn't find evidence it was necessary on its own with @supabase/supabase-js 2.106.0 once REPLICA IDENTITY was fixed.

Thanks again for the help!