You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm putting this in realtime as it might involve realtime and realtime-js.
First it appears realtime takes 1 to several seconds to set up a subscription successfully to handle a change report, is this expected?
Second supabase-js (rc4) / realtime-js .subscribe() fires a SUBSCRIBED event well before the websocket returns a subscribed message in a packet.
To Reproduce
let mySubscription = await supabase
.channel('public.subscribe:uid=eq.'+user.id)
.on('postgres_changes',
{ event: '*', schema: 'public', table: 'subscribe',filter:'uid=eq.'+user.id }, (payload) => {
console.log('Change received!', payload)
}
})
.subscribe((status)=>{
console.log('subscribe = status',status);
if (status==='SUBSCRIBED') {
online.set(true);
}
else if (status !== 'CLOSED') {
online.set(false)
}
})
if ($online) { //simplified but online is a Sveltekit state variable that gets set when 'SUBSCRIBED' is received.
console.log('online now')
let timer = 2000
setTimeout(function() {
console.log('online do update delay by ',timer)
supabase.from('status').update({'update_note_counter': 9}).eq('uid', '74fa50d7-e8a2-4ce7-b894-4e4f3ba75849')
.then(result => console.log('update returned', result))
}, timer);
Expected behavior
.subscribe() should not return 'SUBSCRIBED' until channel is ready to report changes in database
OR provide proper way to get status of channel when it is ready to handle changes.
This is critical for successful use of realtime as one needs to load initial data copy when realtime is setup and ready to report changes and not before (especially if many seconds).
Confirmation from Supabase that realtime can take several seconds to be ready to report changes.
Screenshots
A failure with 2 second delay to an update operation, and a subscribe message in websocket around 3 seconds. The .subscribe() returns subscribed 24.221 and the websocket appears to return subscribed 27.139
A success with 4 second delay to an update operation, and a subscribe message in websocket around 2 seconds.
System information
2.0.0-rc4 supabase.js
Supabase hosted instance
Additional context
This issue was reported in supabase/supabase issues on v1 js. #282
The text was updated successfully, but these errors were encountered:
Bug report
Describe the bug
I'm putting this in realtime as it might involve realtime and realtime-js.
First it appears realtime takes 1 to several seconds to set up a subscription successfully to handle a change report, is this expected?
Second supabase-js (rc4) / realtime-js .subscribe() fires a SUBSCRIBED event well before the websocket returns a subscribed message in a packet.
To Reproduce
Expected behavior
.subscribe() should not return 'SUBSCRIBED' until channel is ready to report changes in database
OR provide proper way to get status of channel when it is ready to handle changes.
This is critical for successful use of realtime as one needs to load initial data copy when realtime is setup and ready to report changes and not before (especially if many seconds).
Confirmation from Supabase that realtime can take several seconds to be ready to report changes.
Screenshots
A failure with 2 second delay to an update operation, and a subscribe message in websocket around 3 seconds.
The .subscribe() returns subscribed 24.221 and the websocket appears to return subscribed 27.139
A success with 4 second delay to an update operation, and a subscribe message in websocket around 2 seconds.
System information
2.0.0-rc4 supabase.js
Supabase hosted instance
Additional context
This issue was reported in supabase/supabase issues on v1 js. #282
The text was updated successfully, but these errors were encountered: