supabase / supabase

The open source Firebase alternative. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.
https://supabase.com
Apache License 2.0
74.23k stars 7.2k forks source link

Disabling "Realtime" for a single table disables realtime for the entire database #26897

Open sagitarious12 opened 6 months ago

sagitarious12 commented 6 months ago

Bug report

Describe the bug

In my supabase instance I have realtime enabled on 4 different tables. I was working on building out a new table which needed to be realtime enabled and so I turned it on. Later, I needed to turn it off as I continued development of my feature, from the table view I clicked on the "Realtime On" button so that I could turn it off for this table. When I viewed my other tables, they still showed "Realtime On". But for each of the other tables that were still On, there were no events being triggered. I should also mention that when I went to the table that I had previously turned off, I clicked on the "Realtime Off" button to enable realtime for this table again and it ended up Re-enabling realtime for all of the other tables that were supposed to have always been on in the first place.

To Reproduce

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

step 1: have two tables or more that each have realtime enabled (in my case all of said tables are in a schema other than public)

step 2: using the js sdk subscribe to each of the tables (in my case I am listening to the INSERT events for all of them)

this.db
    .channel('order-schema-changes')
    .on('postgres_changes', {
          event: 'INSERT',
          schema: 'order',
          table: 'infinity_rips'
    }, async (payload: any) => {
          console.log("INSERTED INTO INFINITY RIPS", payload)
    })
    .on('postgres_changes', {
           event: 'INSERT',
           schema: 'order',
           table: 'header_designs'
     }, async (payload: any) => {
           console.log("INSERTED INTO HEADER DESIGNS", payload);
     })
     .subscribe();

step 3: perform insert to verify realtime events are triggered in js code. (my code has been working for several months just fine)

step 4: go onto one table and click the following buttons: image image

step 5: check a table that isnt the one that you disabled that is supposed to have realtime enabled and see that the UI shows that is is still enabled.

step 6: perform an insert into a table that is not the one that was just disabled

step 7: verify that there was no event triggered in the js code even though realtime is still enabled.

step 8: re enable the table that was previously disabled

step 9: perform an insert into the same table as step 5

step 10: verify that realtime is now enabled again for all of the other tables.

Expected behavior

Clicking on the disable realtime for one table should only disable realtime for that one table.

System information

sagitarious12 commented 5 months ago

Here is all of the postgres commands that I used to setup a test environment to verify the issue in a fresh environment with no other tables besides the ones created in this script:

CREATE SCHEMA "order";

GRANT USAGE ON SCHEMA "order" TO anon;

create table
  "order".infinity_rips (
    id bigint generated by default as identity,
    height bigint null,
    constraint infinity_rips_pkey primary key (id),
  ) tablespace pg_default;

GRANT ALL ON TABLE "order".infinity_rips TO anon;

ALTER TABLE "order".infinity_rips ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Enable read access for all users" ON "order"."infinity_rips"
AS PERMISSIVE FOR ALL
TO anon
USING (true);

create table
  "order".header_designs (
    id bigint generated by default as identity,
    design_name text null,
    constraint header_designs_pkey primary key (id),
  ) tablespace pg_default;

GRANT ALL ON TABLE "order".header_designs TO anon;

ALTER TABLE "order".header_designs ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Enable read access for all users" ON "order"."header_designs"
AS PERMISSIVE FOR ALL
TO anon
USING (true);

INSERT INTO "order".infinity_rips 
  (height) 
VALUES 
  (2);

INSERT INTO "order".header_designs
  (design_name)
values
  ('some design');
GaryAustin1 commented 5 months ago

This is discussed a bit more here: https://github.com/orgs/supabase/discussions/26896 I suspect this is being an issue with making changes while the subscription is running on two tables from the client and getting errors on one impacting the other as they are in the same channel.