Okay, this solved it!

Users from the future;

• in the supabase admin, check the realtime schema subscription table, if your subscription is not there, there is a jwt/auth problem
• if you create your jwt by hand, you should add a role: "anon" field to it at least

Thanks!

@w3b6x9 no problem! Nice work on Realtime btw, been digging through the elixir and enjoying it.

As an aside, I added this tiny PR to the Realtime repo which was helpful when I was debugging my local build. Not sure how interested in it you’d be: https://github.com/supabase/realtime/pull/248

I know this is not the exact same issue as described by OP, but I just wanted to document it here just in case anyone stumbles across the similar issue described, but the solutions don’t work:

I was on all of the latest versions of the CLI, javascript client, etc., with replications and realtime enabled on all tables (including ones without any RLS, just for debugging this) and realtime was only failing locally (my cloud Supabase project, which is an exact replica schema-wise, worked perfectly). Based on @tg44 's advice (“check the realtime schema subscription table”), I went to locate this table, and for some reason, my local supabase realtime schema had no tables. Running supabase db reset did nothing to solve the issue; stopping (supabase stop) and then re-starting (supabase start) the local instance did not help either.

Ultimately, I stopped the running local supabase in the project that I was in (supabase stop) and moved to a completely empty directory, fired off supabase init and then supabase start. I noticed that after doing this, now with a completely blank project, the realtime schema was no longer empty and had the subscription table (as it should). The really odd thing is that I returned to the old project where this bug was occurring, and everything works like normal again, including realtime.

In case anyone stumbles across this thread while chasing down the rabbit hole, ^ helped me to solve the issue. I think the hard reset must have fixed things.

From this context I was able to cobble together a bash script which seems to fix the issue for me, even if it’s an extremely ghetto hack.

#!/bin/bash

# Drop the realtime schema and recreate it so that the realtime container
# is forced to reinitialize everything in the schema.
psql "postgresql://supabase_admin:postgres@localhost:54322/postgres" <<EOF
  DROP SCHEMA IF EXISTS realtime CASCADE;
  CREATE SCHEMA realtime;
EOF

if [ $? -ne 0 ]; then
  echo "Error: Failed to fix local realtime schema."
  exit 1
fi

# Find container ID with name containing "realtime"
container_id=$(docker ps --filter "name=realtime*" --format "{{.ID}}")

# Check if a container was found
if [ -z "$container_id" ]; then
  echo "No Docker container with name containing 'realtime' found."
  exit 1
fi

docker restart "$container_id"

I am running this after the local supabase environment is created.

It looks like the realtime container attempts to create the schema, its tables, its functions, types etc. on start up (if they don’t exist?), so remaking the realtime schema in the database and then restarting the realtime container seems to fix the issue.

I know this is not the exact same issue as described by OP, but I just wanted to document it here just in case anyone stumbles across the similar issue described, but the solutions don’t work:

I was on all of the latest versions of the CLI, javascript client, etc., with replications and realtime enabled on all tables (including ones without any RLS, just for debugging this) and realtime was only failing locally (my cloud Supabase project, which is an exact replica schema-wise, worked perfectly). Based on @tg44 's advice (“check the realtime schema subscription table”), I went to locate this table, and for some reason, my local supabase realtime schema had no tables. Running supabase db reset did nothing to solve the issue; stopping (supabase stop) and then re-starting (supabase start) the local instance did not help either.

Ultimately, I stopped the running local supabase in the project that I was in (supabase stop) and moved to a completely empty directory, fired off supabase init and then supabase start. I noticed that after doing this, now with a completely blank project, the realtime schema was no longer empty and had the subscription table (as it should). The really odd thing is that I returned to the old project where this bug was occurring, and everything works like normal again, including realtime.

In case anyone stumbles across this thread while chasing down the rabbit hole, ^ helped me to solve the issue. I think the hard reset must have fixed things.

@tg44 you saved our day 🥳

Ah, your checklist did the trick!!! I did not realize the importance of the role field. Makes perfect sense in retrospect.

and has at least a role in JWT claims plus whatever else you need to satisfy your RLS policies.

Thanks so much for your help / patience.

@Marviel Thanks for reporting this issue! I’ll investigate shortly and post here with my findings.