Bug: Push settings says "ON" even when current user is not actually subscribed

[hobodave]

Summary

There is a mismatch between what the Notifications Settings UI says and what the server can actually deliver.

Right now, Settings can show push as enabled based on local browser/PWA subscription state alone. But push delivery is server-side and tied to Current.user.push_subscriptions.

So in account-switch / identity-switch flows, users can see “ON” and still not receive pushes for the current user.

Why this matters

This creates false confidence and makes debugging brutal:

• “It says ON, why am I not getting notifications?”
• We end up chasing payload/provider issues when the real problem is user-to-endpoint linkage on the server.

Repro (realistic)

1. Same device/PWA, same origin.
2. Identity has multiple users across accounts (or switch identities).
3. Enable push for User A (server row exists for A).
4. Switch to User B where server row does not exist.
5. Settings still appears ON due to local getSubscription().
6. Pushes for User B are not delivered.

Root cause

Client-side settings state is local-subscription driven.
Server-side delivery is user-row driven.
No status check currently confirms local endpoint is linked to current user.

Proposed fix

• Add per-user status endpoint:
  • GET /users/:id/push_subscription_status
  • returns:
    • has_server_subscription
    • local_matches_server (when client sends local endpoint)
• On settings load (Notification.permission === "granted"):
  1. read local subscription
  2. attempt idempotent sync POST for current user
  3. fetch status and render state from server truth
• UI states:
  • ON only when local_matches_server == true
  • SYNC NEEDED when local exists but server does not match
  • OFF / BLOCKED as appropriate

Scope

• This issue is about per-current-user truth and sync.
• It does not solve full cross-identity endpoint isolation on shared devices

Acceptance criteria

• Settings no longer shows false ON for current user without matching server endpoint.
• Switching users/accounts on same device updates state accurately.
• Re-sync path repairs drift without requiring uninstall/reinstall.

The Human Speaks

Yes, Codex wrote most of the above. I am very grateful for Fizzy being open source. I'm using an identical Identity/Account/User multi-tenancy model, and used your notifications implementation as well. This bug took me the better part of a day (even with Codex) to track down. I have a fix in place for my (private) repo. I'm happy to do the work, the solution I (we?) came up with is loosely outlined above. Let me know if I need to fire Codex. 😄

[hobodave]

Would it help if I provided a failing test case?