Without requireInteraction, the OS default auto-dismiss (a few seconds
on most platforms) was closing notifications before they were
reliably noticed. Browser/PWA push only -- the Desktop bridge is a
separate codebase with its own native notification handling.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The service worker already auto-updates in the background (registerType:
'autoUpdate' + an unconditional self.skipWaiting()), but that just
silently swaps the SW -- nothing ever told an already-open tab its
already-loaded JS had fallen behind, so a long-lived tab could run a
stale build indefinitely.
Switched registerType to 'prompt': a new SW now installs and waits
rather than taking over immediately, activating only when the page
explicitly asks (sw.ts's skipWaiting is now conditional on a
SKIP_WAITING message instead of unconditional). UpdateBanner.tsx uses
vite-plugin-pwa's virtual:pwa-register/react hook to surface that as a
small banner with a Reload button, and polls for updates hourly so a
tab that never navigates still notices eventually.
Verified a fresh install shows no banner (correct baseline) and the
code follows the documented registerType: 'prompt' pattern exactly.
Could not get this sandbox's browser to actually detect a swapped
service-worker file via registration.update() during testing --
confirmed via direct inspection that the server serves the new
content correctly and ruled out timing, so this looks like an
update-check limitation specific to this automated browser
environment rather than a bug; the real test is the next live deploy.
Also adds a "frontend-preview" launch.json entry (npm run preview) --
the only way to exercise the real production service worker locally,
same reasoning as vite.config.ts's existing `preview.proxy` section.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The service worker cached /api/rooms/mine, /api/rooms, .../messages,
.../members, and /api/invites/mine with StaleWhileRevalidate: serve
the previous cached response immediately, refresh the cache in the
background for next time. That means every repeat visit showed
content one visit behind -- reopening a room after someone messaged
it, or checking a second device, both showed stale data until a
manual reload (which finally picked up the now-revalidated cache).
Only registers in a production build (vite dev never activates it),
which is why this didn't surface during in-browser testing this
session for #26/#27/#34.
Switched all five routes to NetworkFirst: always prefer a live
response, fall back to cache only when the network request itself
fails or times out (genuinely offline), keeping the "readable while
offline" behavior without the staleness.
Verified against a real production build (`vite preview`, the only
way the SW actually registers): sent a message from a second session
against an already-cached room, and the very next fetch showed it
immediately with no staleness.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Backend: PushSubscription model/migration, VAPID config + `cli.py
generate-vapid-keys`, push_service.send_push_to_user (upsert-by-endpoint
subscribe/unsubscribe, auto-cleanup of expired 404/410 subscriptions),
/api/push/* router, and ConnectionManager now tracks connected user IDs
per room so chat.py can push only to offline members after broadcasting
to online ones.
Two test-infra bugs found and fixed along the way: send_push_to_user
takes the caller's AsyncSession and is awaited inline rather than fired
via asyncio.create_task with its own session (background tasks were
outliving the test event loop); and the ws_client fixture now uses
NullPool to eliminate a connection-pool checkout race that was failing
WS tests intermittently.
Frontend: service worker rebuilt with vite-plugin-pwa's injectManifest
strategy (custom src/sw.ts) so it can add push/notificationclick
handlers alongside the existing precaching and StaleWhileRevalidate
routes ported over from generateSW. New subscribe/unsubscribe flow
(lib/push.ts, api/push.ts) with a toggle in the account menu.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ksmithandClaude Sonnet 5