trigger on net._http_response, which modifies data in another table, does not trigger Realtime update

[scholz-timo]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

trigger on net._http_response, which modifies data in another table, does not trigger Realtime update

To Reproduce

• create a trigger on net._http_response which insert received data into another table
• have realtime enabled on the table with the inserted data
• make an api call using net.http_get
• wait for realtime event (no realtime event gets called in time (maybe a apply_rls call is missing for StartTransactionCommand and CommitTransactionCommand)
• after 10-30 sec a event is received, prob via fallback realtime sync

create table uuids(uuid uuid not null default gen_random_uuid());

CREATE FUNCTION do_insert_uuid() RETURNS trigger LANGUAGE plpgsql as $$ BEGIN

INSERT INTO uuids(uuid) VALUES (DEFAULT);

END;
$$;

CREATE TRIGGER insertUUID
AFTER INSERT ON uuids FOR EACH ROW
EXECUTE function do_insert_uuid ();

alter publication supabase_realtime
add table uuids;

Expected behavior

Update should happen faster.

Screenshots

If applicable, add screenshots to help explain your problem.

System information

• OS: [e.g. macOS, Windows]
• Browser (if applies) [e.g. chrome, safari]
• Version of supabase-js: [e.g. 6.0.2]
• Version of Node.js: [e.g. 10.10.0]

Additional context

Add any other context about the problem here.

Additional performance hits could be mitigated by using a feature flag for the suggested changes.

[scholz-timo]

Of course, there is a postgresql replication_slot missing.
Only CommitTransactionCommand should have the apply_rls_call().

Optimally there should be a seperation between async and sync requests, maybe extend the request table with an flag if fast updates should be enabled.

[olirice]

A small delay between when you call net.http_get and get a realtime update is expected. The background worker that makes HTTP requests polls with a 1 second interval, the HTTP endpoint could be sluggish, and realtime also polls for changes

The background worker and realtime poller shouldn't account for > 3-5 second though, so if you're seeing 30 seconds thats likely caused by resource contention on the database, a slow response from the HTTP server, or something like that

---

Could you please take another look at the reproducible example from your first message? pg_net is not referenced

A complete copy/paste reproducible example of the issue you're facing will help us a lot in debugging

[steve-chavez]

create a trigger on net._http_response which insert received data into another table

Is not recommended to do that, the net tables shouldn't be modified. Insertions to the response table should be as fast as possible. (this could change once #62 is done).

#139 also improves speed, I suggest you try again once a new version of pg_net is released.

[steve-chavez]

I suggest you try again once a new version of pg_net is released.

new version already released https:/supabase/pg_net/releases/tag/v0.11.0