![]() UserA has a message added to their Minimongo store with “temp: true” which makes the message appear gray in the UI. However, when the actual message is sent by UserA, the oplog is involved. After looking at the code a bit it seems that the “typing…” notification is handled by the rocketchat:streamer package and doesn’t involve the oplog since it’s just UserA emitting a DDP notification to the server on the “notify-room” stream and UserB (who is subscribed to that stream) receiving the notification. I was curious why the “UserA is typing…” notification appeared to UserB but the actual message never arrived. ![]() I wonder if there is an issue related to periods of inactivity where something gets disconnected and doesn’t properly reconnect? This occurred after my production server had not had any traffic for a couple days. So after rebooting my production RC server, the problem went away. I’m still actively working on this issue and looking at the RC code so I’ll post more updates as I learn more. Production is using MongoDB Atlas cluster with 3-node replica set Local is using local MongoDB server with single-node replica set (NOT the built-in one that ships with Meteor, I have a separate mongo server running locally) Production is using HTTPS with custom domain name (via Caddy Auto-SSL / Lets Encrypt) Production is using Caddy 2.2.1 as reverse proxy Production is using a custom Meteor bundle that I build on a Linux box, then upload to the production server Local is running in usual dev mode ( meteor npm start) This seems like possibly the same issue described here (except they’re running on Heroku): ĭifferences between my local machine and production environment: I also turned on Caddy logs to debug level and don’t see anything useful there (no relevant errors). It works fine on my local dev machine, but when I deploy to production, I can reproduce the issue as describes it.Īt first I thought it might be an issue with my production Caddy config around websockets but since we can see the “UserA is typing…” message, that would seem to indicate that the Realtime API subscriptions are receiving fine over websockets. The message got something like a “Temp” status in the web browser console.Īny advice? Version of Rocket.Chat Server: 0.66.1 & 0.68.3ĭeployment Method(snap/docker/tar/etc): tar When the user sends a message to a specific other user or channel the message is greyed out and not delivered to the reciever. Also they can see that someone is typing but the new sent message from the other user doesn’t appear. After relogin they get a DM notification, but they can’t see any new message when they open the chat window. Sometimes our users get an auto disconnect in web browser. I hope somebody knows whats going on on my server. I’ve already opened an issue on github and have seen similiar issues related to mine but still found no solution for this problem.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |