Realtime Postgres Changes Not Received for async_jobs Updates Despite Correct Setup

[veravox-daan]

Hi Supabase Community,

I'm encountering an issue where my client application is not receiving Realtime postgres_changes events for updates to my public.async_jobs table, despite seemingly correct configuration and extensive troubleshooting.

Goal:

I have a background job system using an Edge Function -> AWS Lambda. The Lambda updates the status and results (result_data JSONB column) of a job in the async_jobs table. My React Native application needs to listen for UPDATE events on this table (specifically for a given job ID) to notify the user when the job is complete or failed.

Setup:

• React Native client using supabase-js.
• public.async_jobs table tracks job status (text), user_id (uuid), result_data (jsonb), etc.
• Edge Function triggers Lambda, inserts initial 'pending' job row.
• Lambda function updates job row status to 'processing', then 'completed' or 'failed', including result_data.

Client Code (Intended Implementation):

My client code aims to subscribe like this (simplified):

const setupJobSubscription = (jobId) => {
const channel = supabase.channel(job-updates-${jobId}) // Dynamic channel name per job
.on(
'postgres_changes',
{
event: 'UPDATE', // Matches "Subscribe to updates"
schema: 'public', // Matches all examples
table: 'async_jobs', // Matches all examples
filter: id=eq.${jobId} // Matches "Subscribe to specific rows" concept
},
(payload) => {
console.log('--- JOB UPDATE RECEIVED ---:', payload);
// ... processing logic based on payload.new.status ...
}
)
.subscribe((status, err) => {
if (status === 'SUBSCRIBED') {
console.log(Successfully subscribed to job updates for ${jobId}); // <-- THIS LOG APPEARS
} else {
console.error('Subscription error:', err);
}
});
// ... (store channel ref, handle cleanup) ...
};

The Problem:

The client successfully subscribes (the "Successfully subscribed..." log appears), and the backend Lambda function correctly updates the async_jobs row in the database (verified via Lambda logs and checking the table data directly). However, the (payload) => { ... } callback in the .on() listener never fires. No payload is received by the client.

Troubleshooting Steps Taken:

1. RLS Policies:

• Confirmed correct RLS policies exist for async_jobs:
• SELECT allowed for authenticated USING (auth.uid() = user_id).
• INSERT allowed for authenticated WITH CHECK (auth.uid() = user_id).
• Temporarily disabled RLS entirely on async_jobs - still no events received.

2. Realtime Toggle: Confirmed "Enable Realtime" is ON for async_jobs in the Supabase Table Editor UI.
3. Publications: Confirmed via Dashboard (Database -> Publications) that public.async_jobs is listed as part of the supabase_realtime publication. Also ran ALTER PUBLICATION supabase_realtime ADD TABLE public.async_jobs; via SQL Editor (it confirmed the table was already included).
4. Backend Updates: Verified via Lambda logs and direct table inspection that the Lambda function is successfully updating the status and result_data columns of the relevant async_jobs row.
5. Listener Variations: Tried numerous variations of the client listener, none of which received payloads:

• Using static channel names (e.g., 'schema-db-changes').
• Using event: ''.
• Removing the filter clause.
• Removing the table: 'async_jobs' clause entirely (listening to schema: 'public', event: '').

14. Different Table/Event:

• Enabled Realtime for public.conversation_messages.
• Changed listener to event: 'INSERT', table: 'conversation_messages'.
• Manually inserted a row into conversation_messages via the Supabase dashboard. Still no event was received by the client.

Conclusion:
Despite following the documentation examples and trying various configurations, I haven't been able to receive postgres_changes events, even when manually triggering changes on a different table (conversation_messages). The client subscribes successfully, RLS seems correct (and was disabled for testing), the table is in the publication, and the database updates are confirmed.
I'm currently stuck on why the events aren't being delivered. Is there any other configuration setting I might be overlooking, a common pitfall I've missed, or any further diagnostic steps I could take on the client or backend to pinpoint the cause? Any insights or suggestions would be greatly appreciated!
Thanks for any help!

[GaryAustin1]

Try the dashboard realtime monitor to confirm your instance is working correctly. You can impersonate a user to verify even that is working.

[veravox-daan]

Thanks very much. Not sure how I missed that feature :-) Wasnt the answer so I wont mark it as such but it definitely helped me on the right path! Issue sorted! :-) Thanks man.

[Gideon1107]

Hi, how did you solve this? i'm currently experiencing the same thing