-
Notifications
You must be signed in to change notification settings - Fork 448
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Notifications are not reliable #14296
Comments
We're so close to use Talk as a replacement for another solution, but the unreliable notifications may prevent this from happening. 😢 That's a bummer, because otherwise Talk works perfectly fine. |
In group chats only mentioned participants or in case of a reply the author of the original message receive a notification, unless you change the admin setting:
Can not really reproduce this, unless specifically opting out of call notifications:
Can you name "pretty high delay"? Does it match below description?
Can you post a screenshot of
As well as |
Yes, I've changed the setting to "All messages" already. (The global default was changed and all users have it set to "All messages".)
Yeah, 100% reproducability would be great, but I couldn't find a pattern so far.
I've already added notify_push. But notifications are still delayed. Yesterday I did another test: some notifications arrived immediately, while others were delayed for approx. 5-20s. It does not seem to matter whether I use a browser (Firefox) or Talk Desktop (on Linux Mint). But other users said they did not receive a notification at all, just noticed an ongoing group call by chance (after several minutes).
Here's the output:
Not sure if this could be related, but I've noticed that the number of open file handles increased dramatically after enabling notify_push (nextcloud/notify_push#560). |
Can you reproduce the delays when you use the |
I've successfully tested this command on all web servers:
This command works perfectly fine when using Nextcloud/Talk in a browser. When using Talk Desktop no notification is received, but I assume this is expected, because Desktop Talk cannot handle the However... I think I can reproduce the delayed/missing notifications. Assuming two users in 1:1 chat:
Steps to reproduce:
NOTE 1: It's not always the 2nd notification that is missing. But according to my testing one out of three notifications is always missing. NOTE 2: Only messages from user2@browser to user1@talk-desktop cause missing notifications. (When user1@talk-desktop sends messages to user2@browser not a single notification gets missing.) NOTE 3: If both user1 and user2 use Talk in a browser, then notifications are 100% reliable (according to my testing). Not receiving 1 out of 3 notifications is probably not a big deal, but it may help to find the reason why any notification is not received (as I already said some users almost never get notifications). So far only notifications in Talk Desktop are reproduceable missing. Should I file a bug for the talk desktop app, or could it still be related to spreed, notify_push or another server component? I've collected some logs... notify_push service log (debug log level):
user2@browser console log:
user1@talk-desktop console log:
|
|
It seems the notify_push is grouping the pushes by 1s
The sending part makes no difference. |
I think I tracked something down. On my prod desktop client The same is also visible in your logs of user1@talk-desktop:
|
|
Neither of them shows a notificaton in Talk Desktop. Is this expected? |
At the moment: yes |
But you will already see the info in the console of the desktop client |
Shall we show the test notification in Talk Desktop? |
How to use GitHub
Steps to reproduce
Not easy to reproduce, the notification behaviour seems pretty unpredictable (see below). 😕
Expected behaviour
All messages and calls should result in reliable notifications on Web UI and Talk Desktop, and on all devices (if the user is logged in on multiple devices).
Actual behaviour
NOTE: notify_push is already configured (and recognized by the Talk Desktop application), but it looks like this did not solve the issue.
Talk app
Talk app version: 20.1.3
Custom Signaling server configured: yes
Custom TURN server configured: yes
Custom STUN server configured: yes
Browser
Microphone available: yes
Camera available: yes
Operating system: Ubuntu, Linux Mint, Mac
Browser name: Firefox, Chrome and Safari
Browser version: most recent versions :)
Browser log
Server configuration
Operating system: RedHat
Web server: Apache –> 3 web servers running Nextcloud (php-fpm) and a loadbalancer
Database: MySQL (Galera Cluster)
PHP version: 8.3
Nextcloud Version: 30.0.5
List of activated apps:
Nextcloud configuration:
Server log (data/nextcloud.log)
The text was updated successfully, but these errors were encountered: