Repository navigation
feat: sync notification read state across sessions - #334
Merged
Merged
Conversation
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
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.
Reading notifications in one signed-in session now clears the account’s unread badge in its other sessions. An attested, private SpacetimeDB watermark merges local/offline progress by maximum, so an older session cannot undo newer reads. New notifications still become unread; each open Notifications visit keeps its initial row highlighting and selected tab.
The Rust controller connects after initial page work, uses separate notification credentials, and subscribes only to the caller’s state. It handles reconnects and account changes without creating public chat presence or DM keys. Messages and notification sync share the official SDK loader with owned callback cleanup. The module update is additive; existing chat and encrypted DM tables are unchanged.
Validation
Production rollout requires the additive module publish before deploying the app. CI and first-deployment performance checks remain required. No live public messages or DMs are part of validation.