Hi.
We have an application which allows users to chat in real-time using sockets. We also have redis and bull queues configured to handle concurrent message send/receive requests. We process avg ~5000 requests every hour - so not very high in terms of usage.
We get random complaints from users saying that new messages are not showing up - which translates to sockets not being delivered reliably. It usually just fixes itself.. or user has to refresh the page.
I was thinking of adding some sort of logging to the socket emit flow.. to capture if sockets are failing to reach the client systems.
Looking at socket-io docs, I found this: Emitting events | Socket.IO
It shows that there are callback and error handling events built-in. But I don't think Wappler has this configured in their implementation.
So the question is - what is your approach/recommendation around logging socket activity and can some approach be implemented the Wappler-way? Maybe involve Redis in the mix as well?
Socket connections are initiated by the client, messages travel through it. If the connection drops, the client should report the error. Search about using Sentry for front-end - I use GlitchTip which is a third-party Sentry alternative
Probably it's already integrated into Sentry's front-end framework:
The question I now have, does the client attempts to re-establish the socket connection once it's lost?
If yes, then the problem may be it doesn't know it has to refresh the messages, because the message vanished because the client wasn't connected at the time - the mechanisms to guarantee a delivery of an offline client are out-of-scope of socket.io I believe.
"Easiest" way is to make Wappler to refresh/reload the server connect once the socket connection is re-established (this would be a feature request most likely, or you could play with those emit events to run dmx.parse("sc_messages.load()") or something)
Remember, as far as I know, Wappler socket messages are simply instructions for a server connect to be reloaded. Disclaimer: I've never used Wappler sockets
We used Sentry briefly on this app, before disabling it. Maybe we need to revisit that, or other alternatives like GlitchTip.
Not really sure what the socketio instrumentation means or how it works - but looks helpful.
This is actually handled by Wappler's implementation of socketio library. And we show the user a big red alert when socket connection drops - and it auto-hides once connection is restored.
The issue video reported by user does not show the disconnection state - which is why I need some way to log and debug this problem.