supabase: 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:

Create project -> create new table -> set “Enable Realtime”
Copy project url and project api key (anon public) from settings > api
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()

run script (node test.js)
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.

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 2
Comments: 16 (3 by maintainers)

Most upvoted comments

@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…

GaryAustin1 on Sep 6, 2022

Just to clarify on the strict mode… What I think several users have encountered with react useEffect, where they subscribe and unsubscribe on cleanup, is that running the useEffect a second time causes a timing issue. The subscribe starts up correctly then the useEffect gets called again so launches the cleanup routine and sends a close subscription to the server, meanwhile the “new” subscription starts up, but sees the close coming back from the server from the first subscription and closes everything on realtime-js side.

Strict mode causes the useEffect to run twice, similar to a former issue where the user switched pages each with the same useEffect subscription a month or so ago.

GaryAustin1 on Jul 19, 2022

@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.

w3b6x9 on Jul 19, 2022