tuskyapp
Bug: Tusky doesn’t retry setting new UnifiedPush/WebPush endpoints with Mastodon
-
Tusky Version: master and 24.0
-
Android Version: Android 14
-
Android Device: Pixel 6a
-
Mastodon instance (if applicable): gultsch.social
-
[x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
Conversations and possibly other UnifiedPush Distributors occasionally update push endpoints and send them to Tusky via a NEW_ENDPOINT broadcast.
This behaviour usually works. However if the update happens during spotty internet connection or when the mastodon instance is temporarily overloaded and the 'update endpoint' call to mastodon fails Tusky doesn’t retry setting endpoint and instead unregisters the endpoint with the distributor.
The offending code is here: https://github.com/tuskyapp/Tusky/blob/331b13621e68fe22a4efa0e42141c890a1c1786e/app/src/main/java/com/keylesspalace/tusky/components/notifications/PushNotificationHelper.kt#L185
Instead of 'unregister' it should schedule a 'try again later'. Either with the same endpoint URL (ideally) or at least schedule a 'request new endpoint on Distributor and then register that with Mastodon'
Edit: because of https://github.com/tuskyapp/Tusky/issues/2806 this leaves push notifications permanently broken until a log out of the account.
@nikclayton I think this issue is a possible reason for the previously discussed case of notifications stop working after some time. I'm using Pachli for quite a while now and your information on "debuggging notifications", i.e. to log out and back in the account in Pachli helps to regain notifications.
This is the output of Pachli's debug info after notifications stopped working: pachli-notification-logs-2024-08-29-09_33_32 (1).txt
Is there a way this can be improved in Pachli?
Hey team, this is not the correct forum for discussions about pachli, thanks 🙂
You're absolutely right, I'd appreciate a fix for Tusky equally well! :-)