Presence not working as of supabase-js 2.54
Opened this issue · 13 comments
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
In any client pages using version 2.54 or 2.55 of supabase-js, presence simply doesn't work.
To Reproduce
- Create two standalone HTML pages page1.html and page2.html.
- Add a script to both which imports supabase-js@2.54
- In page1.html add tracking state example from the docs.
- In page2.html add sending state example from the docs
- Open both pages. Observe console logs of presence successfully initing but no logs of the sending state being received by the tracking page
Repeat the above steps but change import to version 2.53 or earlier and observe presence being sent as expected.
Expected behavior
Presence of the sending page is received by the tracking page.
Screenshots
Full code snippet of reproduction pages. Replace xxx and yyy with your own public ID and token.
page1.html
<html>
<head>
</head>
<body>
<script type="module">
import { createClient } from 'https://cdn.jsdelivr.net/npm/@supabase/supabase-js@2.54/+esm'
const supabase = createClient('https://xxx.supabase.co', 'yyy', {
});
const roomOne = supabase.channel('room_01');
console.log("room1 open")
roomOne
.on('presence', { event: 'sync' }, () => {
const newState = roomOne.presenceState()
console.log('sync', newState)
})
.on('presence', { event: 'join' }, ({ key, newPresences }) => {
console.log('join', key, newPresences)
})
.on('presence', { event: 'leave' }, ({ key, leftPresences }) => {
console.log('leave', key, leftPresences)
})
.subscribe()
</script>
</body>
</html>page2.html
<html>
<head>
</head>
<body>
<script type="module">
import { createClient } from 'https://cdn.jsdelivr.net/npm/@supabase/supabase-js@2.54/+esm'
const supabase = createClient('https://xxx.supabase.co', 'yyy', {
});
const roomOne = supabase.channel('room_01')
const userStatus = {
user: 'user-1',
online_at: new Date().toISOString(),
}
roomOne.subscribe(async (status) => {
if (status !== 'SUBSCRIBED') { return }
const presenceTrackStatus = await roomOne.track(userStatus)
console.log(presenceTrackStatus)
})
</script>
</body>
</html>Now edit the version string to 2.53 or earlier and try again and observe it working.
System information
- Browser: Tested in Chrome & Firefox
- Version of supabase-js: 2.54 & 2.55 (latest at time of submission)
Hi @filamentumbrella ! Thanks for your bug report. It seems to be working on my end. I have this demo project that I test the realtime features. Can you please check it out: https://github.com/mandarini/my-test-sb-proj it's based on the examples on the website, and it uses the latest version of supabase-js, 2.56.0.
Here's the deployed version: https://sb-kat-demo.netlify.app/
Hi @mandarini - I have created an absolute bare bones example using my code above.
If you open both the below tabs you will see no presence acknowledgement in either. These are using supabase-js from https://cdn.jsdelivr.net/npm/@supabase/supabase-js@2.56/+esm which still has the issue:
https://legendary-cucurucho-924aaf.netlify.app/test1-256.html
https://legendary-cucurucho-924aaf.netlify.app/test2-256.html
If you open both these below tabs you will see the acknowledgement as expected. The only difference between these 2 pairs of pages is importing version 2.56 (broken) and 2.53 (working):
https://legendary-cucurucho-924aaf.netlify.app/test1-253.html
https://legendary-cucurucho-924aaf.netlify.app/test2-253.html
I appreciate you have a provided working example, but there is a lot of additional unrelated code there which may be having an affect on this bug manifesting. Hopefully my example pages showing absolutely nothing other than Supabase's own example presence code will help to isolate the issue and show that the error can only possibly be due to something not working in the file hosted in jsdeliver.
Thank you for sharing this @filamentumbrella . I am going to take a look tomorrow and get back to you!
@filamentumbrella we tested with latest (2.56.1) and it works now! Can you test as well? Thank you for submitting this issue!!!
Hi @mandarini thanks for your quick attention on this issue. Unfortunately though I am still seeing the same issue with 2.56.1.
Here's an updated pair of test pages on the netlify site:
https://legendary-cucurucho-924aaf.netlify.app/test1-2.56.1.html
https://legendary-cucurucho-924aaf.netlify.app/test2-2.56.1.html
The only difference here is that these are now hard coded to 2.56.1 from jsdeliver. As before, the console logs show everything initializing correctly, but the presence of the second page is never acknowledged by the first.
The pair of pages hard coded to 2.53 still to work as expected.
Incidentally, I still had test1-2.56.1.html open when testing the 2.53 version and I noticed that it did successfully acknowledge the 2.53 tab's presence, so the issue is perhaps to track() not working in the example code i.e.
const roomOne = supabase.channel('room_01')
const userStatus = {
user: 'user-1',
online_at: new Date().toISOString(),
}
roomOne.subscribe(async (status) => {
if (status !== 'SUBSCRIBED') {
return
}
const presenceTrackStatus = await roomOne.track(userStatus)
console.log(presenceTrackStatus)
})We do get the "ok" console log here, so it appears that every other line is working as expected, but whatever track() is sending off behind the scenes is never received by the .on('presence') event listeners in the other page.
In your code do change to
const supabase = createClient('https://<project_ref>.supabase.co', '<anon_key>', {realtime: {presence: {enabled: true}}});
this is required as we are looking into improving overall performance of the system so disabling Presence reduces the number of messages being sent / received. Previously (before 2.56.1) we checked if there were bindings to on('presence') but this is not enough.
we added this configuration to override that in scenarios like yours where you do not want to listen to changes but need to track them (e.g. iot devices)
Hi @filipecabaco - I have updated my two test pages using version 2.56.1 with that config and the issue persists:
Hi @filipecabaco & @mandarini - sorry to ping, but I only just noticed that this issue has been closed and I just want to clarify that it is not fixed. That test scenario is what is currently provided in the docs, version 2.56.1 of supabase-js from jsdelivr.com and the config suggested in Filipe's latest response.
Please let me know if I can do anything else to help isolate the issue, but my two test pages above are fully frontend so you are welcome just copy their source to test them locally.
Thanks
Hi @filamentumbrella ! Thanks, I'll look into it again today!
I have a very similar issue where I need to wait 1sec in a setTimeout before subscribing to postgres_changes.
My code is working on 2.53 but get no payload on 2.54+.
Hello ! Like I said, I had the same issue after an update. Calling await supabaseClient.realtime.setAuth() before subscription solved the problem for me.
It seems like there is a delay from catching the JWT that create the issue when using RLS.
You can find the source for setAuth here: https://github.com/supabase/realtime-js/blob/master/src/RealtimeClient.ts
I sent a message to the support. And they told me to migrate to Broadcast, linking to this blog post: https://supabase.com/blog/realtime-broadcast-from-database
And funny enough in there you can find the same call to supabaseClient.realtime.setAuth() stated as "Needed for Realtime Authorization".
So at this point it looks intended and might just need a doc update.
I sent a message to the support. And they told me to migrate to Broadcast, linking to this blog post: https://supabase.com/blog/realtime-broadcast-from-database
And funny enough in there you can find the same call to supabaseClient.realtime.setAuth() stated as "Needed for Realtime Authorization".
So at this point it looks intended and might just need a doc update.
I figured the entire point of superbase-js existing was to have a neat wrapper specifically so you don't have to go setting that stuff up in your database on every project.
I absolutely believe that's what support told you, but I'll be pretty disappointed if that's the actual intended goal here, because avoiding fiddling with database set up is one of the key selling points of Supabase that brought me to it in the first place.
If what support say is indeed the intended approach moving forward then subscribing to presence shouldn't just silently not work in newer versions of supabase-js, but should instead immediately throw errors saying the code is deprecated or just straight up saying it doesn't exist (and as you rightly say, the docs updated to match that). Right now, all the code is ostensibly still valid syntax so the silent failure appears to be something borked in the supabase-js package... And I'm hopeful that's still the case because the alternative would be a major bummer.