Fixed: notifications issue as the token registration is gated in preferences condition causing the device to not getting registered and subscription fails - #859
Merged
Conversation
…erences condition causing the device to not getting registered and subscription fails
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
This was referenced Sep 17, 2026
dt2patel
added a commit
that referenced
this pull request
Sep 17, 2026
…#878) * Fixed: register the device when subscribing from the preference modal subscribe#Topic only attaches registration tokens the backend already knows about. The notification preference modal, reached from the bell icon, subscribes topics and never registers the device, so a user who sets their preferences there creates subscriptions with no token behind them and receives nothing until their next login, when the login path finally registers and back-fills. That is the shape of the "log out and log back in" folklore around these notifications. The settings screen already registers, and #859's move of the preference gate out of initialiseFirebaseMessaging is already on this branch, so this is the one remaining path that can subscribe without registering. Also stopped an unset or malformed VITE_FIREBASE_CONFIG throwing out of JSON.parse, where the rejection propagated out of the post-login flow instead of degrading to notifications being unavailable. Deliberately NOT changed here, both worth a decision of their own: - The subscribe-then-register ordering in Settings is left alone. store#ClientRegistrationToken back-fills a new token into topics the user already holds, so that order does work. I previously claimed it was the bug and was wrong. - The isFirebaseInitialised early return in firebaseUtil is currently commented out on this branch. Leaving it commented re-runs initialiseFirebaseApp on every call and re-attaches onMessage, which duplicates in-app notifications. It should be restored once accxui#165 stops that flag being persisted, since persistence is presumably why it was disabled. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Fixed: do not reinitialise messaging for an already-registered device The preference modal called initialiseFirebaseMessaging on every save. Its initialisation guard is commented out in firebaseUtil on this branch, so each call attached another foreground onMessage listener and an already-registered user accumulated one per save, with later notifications landing in the store several times over. Registration now runs only when this device has no token yet. getFirebaseDeviceId is set once a token has been stored, so it answers "has this device registered" without re-entering initialisation, and it does not depend on the persisted isFirebaseInitialised flag, which rehydrates as true in a context that has no Firebase app. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related Issues
Short Description and Why It's Useful
Removed the preferences check from the notification util and moved it to the login flow, so that if notifications preferences are not found on login do not register the device, but if someone is subscribing from the settings page, the device registration should be done.
Screenshots of Visual Changes before/after (If There Are Any)
Contribution and Currently Important Rules Acceptance