- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 319
Open
Labels
bugSomething isn't workingSomething isn't working
Description
Bug report
- [ x ] I confirm this is a bug with Supabase, not with my own application.
- [ x ] I confirm I have searched the Docs, GitHub Discussions, and Discord.
Describe the bug
My supabase realtime listener stops receiving events after a while, without giving an errors.
To Reproduce
Here is the code snippet I'm using
async def realtime_insert_table_listener(table: str, cb: callable):
while True:
try:
await async_supabase.realtime.connect()
while not async_supabase.realtime.is_connected:
await asyncio.sleep(0.2)
channel = async_supabase.channel(table)
channel.on_postgres_changes(
event="INSERT",
schema="public",
table=table,
callback=cb,
)
await channel.subscribe(
lambda status, err: status
== RealtimeSubscribeStates.SUBSCRIBED
and logger.info("Successfully subscribed")
)
while True:
await asyncio.sleep(10)
except ConnectionClosedError as exc:
logger.warning(
"Connection closed unexpectedly: %s. Will retry...", exc
)
except Exception as exc:
logger.exception(
"Error in realtime listener: %s. Will retry...", exc
)
finally:
try:
if async_supabase.realtime.is_connected:
logger.info("Closing realtime connection...")
await async_supabase.realtime.close()
except Exception:
logger.exception("Error while closing realtime connection")
# Backoff or small delay before attempting to reconnect
logger.info("Will attempt to reconnect in 5 seconds...")
await asyncio.sleep(5)
System information
- OS: ubuntu
package information:
>>> supabase.__version__
'2.15.2'
>>> realtime.__version__
'2.4.3'
>>> websockets.__version__
'14.2'
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
Marzhal commentedon Jun 22, 2025
Please assign me this issue :)
Rasheek16 commentedon Jun 23, 2025
Can i take up this issue?
silentworks commentedon Jun 24, 2025
@ekorman how long before it stops receiving events? what environment are you running the code above in and how are you running it?
ekorman commentedon Jun 24, 2025
@silentworks i run it like this
inside a docker container (based on
python:3.11-slim
) on an ubuntu VM.hard to say exactly how long before it stops receiving events but seems like it works for between 12-36 hours before no longer receiving messages (or erroring) and never recovering.
skusez commentedon Jul 16, 2025
Experiencing the same, 3.12-slim, supabase 2.16.0 - ubuntu amd64 vps inside docker
I setup a heartbeat that sends a message to the giveaway-events channel using realtime.send from database, it runs every 1 minute. I simply log the message in python
It emits logs exactly 60 times before silently stopping (60 mins)
Ran the same test in supabase studios realtime inspector and logs keep coming through with no hiccups (self hosted, running within the same VPS
)
skusez commentedon Jul 16, 2025
The fact it drops out after exactly 1 hour leads me to believe its linked with the refresh token issue that has a PR open here #1171
silentworks commentedon Jul 16, 2025
@skusez provide a full reproducible example please. This should include the Dockerfile setup along with the Python code. Also have you tested it with the PR you stated above to see if it fixes the issue?
silentworks commentedon Jul 16, 2025
I've setup a test locally that has been running for more than an hour and it's still receiving messages. This test was without the docker container, I'm going to try this now with the docker container to see if it makes a difference.
skusez commentedon Jul 16, 2025
I tested with the PR and still was silently failing around the hour mark, I did have to patch the package as there was a top level await causing a runtime error
My Dockerfile:
silentworks commentedon Jul 16, 2025
@skusez if you had to remove the top level await then there is something wrong about the package version you are using, we have no top level await in the library code.
silentworks commentedon Jul 16, 2025
I've tested this inside of a docker container and still not getting the issue you are having. You can check the code in the repo here https://github.com/silentworks/sb-python-issues/tree/main/supabase_py_1134
Kabya002 commentedon Jul 16, 2025
Hi @skusez — appreciate you testing the PR!
Just to clarify: the main goal of PR #1171 was to fix an
Authorization
header desync after token refreshes — specifically affecting service clients likeauth.admin.list_users()
returning 403s due to stale tokens.The issue you're seeing sounds different:
That said, you're absolutely right to consider whether the realtime client is staying updated after token refreshes — it’s something we now handle via
set_auth(...)
in the patch.Re: the
await self.realtime.set_auth(...)
change — that line is inside an async method, so if you're seeing a top-levelawait
error, you might be testing an older commit. The current version should not raise that.If you end up isolating the 60-minute drop to auth-related behavior, I’d be happy to collaborate on a repro or patch!
silentworks commentedon Jul 16, 2025
@Kabya002 you should state the above on the PR that you opened as there should never be a scenario where
auth.admin.list_users()
has a stale token as it should only ever be called with theservice_role
key. Add the comments above on the PR so we can discuss this further.Kabya002 commentedon Jul 17, 2025
@silentworks I've posted the clarification regarding auth.admin.list_users() and service_role usage in PR #1171 as you suggested.
skusez commentedon Jul 23, 2025
Hey just an update, my errors were actually an internal issue with my VPSs