supabase subscriptions not working

Bug report

Describe the bug

Whilst running a script that is “subscribed” to the table. On inserting values directly into the table through app.supabase the event is not shown.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Create project -> create new table -> set “Enable Realtime”
2. Copy project url and project api key (anon public) from settings > api
3. Here is simple script that creates subscription:

const { createClient } = require('@supabase/supabase-js');

const supabaseUrl = "...supabase.co" //project_url
const supabaseAnonKey = "xxx.xxx.xx-xxx" //project api key (anon public)
const supabase = createClient(supabaseUrl, supabaseAnonKey)

const mySubscription = supabase
  .from('*')
  .on('*', payload => {
    console.log('Change received!', payload)})
  .subscribe()

1. run script (node test.js)
2. insert new row into table

Expected behavior

I would expect to see a print statement consisting of the newly inserted value into the table.

System information

• OS: Windows
• Browser (if applies): firefox
• Version of @supabase/supabase-js: ^1.35.4 (?)
• Version of Node.js: v17.8.0

Additional context

I’m sure the client is connecting because i can pull all the data using:

async function seeAllData(){
  const { data: sales_data } = await supabase.from("test-table").select("*")
  console.log("SALES DATA:", sales_data)
}

RLS is disabled. And looking at the replication section in databases, everything is toggled on. I feel like theres something simple I’m overlooking but I can’t figure out what.

[GaryAustin1]

@kandros This is another related issues with a solution mentioned… https://github.com/supabase/realtime-js/issues/169 The fix appears only to be in v2 client code for that one. Edit: also there are many things that can cause events not to get to the client. You might go to the Supabase Discord server or start a new issue and describe your conditions…

[w3b6x9]

@shini-tm Unfortunately this does not appear to be working. It’s quite serious, as it’s breaking a major workflow through our app.

When attempting to subscribe, I see the following in the browser’s websocket connection logs:

{"event":"phx_reply","payload":{"response":{"reason":"join crashed"},"status":"error"},"ref":"1","topic":"realtime:public:discovers:draft_id=eq.06:c7:cd:01:f6:f0:34:00"}

It looks like there should be logs of the crash reason somewhere, but I won’t have access to those. https://github.com/phoenixframework/phoenix/blob/1636787952c736816312387222347770c9228f38/lib/phoenix/channel/server.ex#L42-L49

This is quickly reproducible on our side when using Supabase Cloud, but not when running Supabase locally.

We are using subscriptions with RLS, so we thought it might be related to supabase/realtime#265, but it appears that our schema is up to date with what is discussed in that thread.

@saterus I think you reached out via support ticket and we resolved it for you. There’s an issue in the latest Realtime version (multi-tenancy) where we’re splitting by : which obviously broke based on your filter value.