No realtime trigger for 'update event' through code, while it works when updating DB directly

[jstdk]

Describe the bug Not sure if I am a noob or that this is a bug. When I update the DB through flutter/supabase package, the update event is not triggered, while it works if I make the same change directly on the DB. In other words, the update event trigger works, but it is not recognized when done through code (even though the update is successful in the DB). Another interesting part is that this only happens on the 'update event', it works fine for inserts and deletes. Am I missing something? Thanks.

This:

Does not trigger this:

As said, the update event does trigger when I set show to false in the DB

To Reproduce Create a realtime table, set a listener for update events. Try to update a row through code and DB and see if it triggers for both

Expected behavior A update of the row would trigger the update event as it does for inserts and deletes

Screenshots See above

Version (please complete the following information):

Additional context Add any other context about the problem here.

[dshukertjr]

@jstdk Could you update your issue by copy and pasting the code instead of pasting screenshots?

Could you also double check if the update actually happens by looking at the table editor? My guess is that the update isn't actually happening when you do it through code, because of RLS issue.

[jstdk]

Sure @dshukertjr. Below the code. I've double checked. The update is happening inside the table editor, both with and without RLS. In a nodjs project I have the same update listener using the Javascript Flutter library, and there it works as expected.

Thanks for any suggestions.

  Future setShowToFalse(messageId) async {
    final result = await supabase
        .from('messages')
        .update({'show': false})
        .match({'id': messageId})
        .select()
        .single();

    if (result != null) {
      return true;
    } else {
      return false;
    }
  }

supabase.channel('public:messages').on(
      RealtimeListenTypes.postgresChanges,
      ChannelFilter(
          event: 'INSERT',
          schema: 'public',
          table: 'messages',
          filter: 'organisation_id=eq.$organisationId'),
      (payload, [ref]) async {
        if (kDebugMode) {
          print('New incoming message');
        }
        await getNewMessages();
      },
    ).on(
        RealtimeListenTypes.postgresChanges,
        ChannelFilter(
            event: 'UPDATE',
            schema: 'public',
            table: 'messages',
            filter: 'organisation_id=eq.$organisationId'),
        (payload, [ref]) async {
      if (kDebugMode) {
        print('New updated message');
      }
      await getNewMessages();
    }).on(
        RealtimeListenTypes.postgresChanges,
        ChannelFilter(
            event: 'DELETE',
            schema: 'public',
            table: 'messages',
            filter: 'organisation_id=eq.$organisationId'),
        (payload, [ref]) async {
      if (kDebugMode) {
        print('New deleted message');
      }
      await getNewMessages();
    }).subscribe();
  }

[jstdk]

I solved it using a different real-time listener. It does not solve the issue with the channels though

    supabase
        .from('messages')
        .stream(primaryKey: ['id'])
        .eq('organisation_id', organisationId)
        .listen((List<Map<String, dynamic>> data) async {
          await retrieveMessages();
        });

[dshukertjr]

@jstdk stream() uses the channel().on() method internally, so if .stream() is working, channel().on() should work as well.

Would you be able to provide a screen recording showing how the update callback is not working for channel().on() method for you?

[rlee1990]

Im also have the same kind of issue

[jstdk]

I will create a screencast, but a little short on time. I need to restore the code as it was.

[dshukertjr]

I'm going to close this issue as updating the rows via the SDK or from the dashboard should not make a difference of whether the realtime listener can react to it. If anyone finds themselves in a same situation, it would be very much appreciated if they could attach a loom video or something similar demonstrating the issue within the video.