fix(client): harden PWA push and resume recovery#120
Conversation
Deploying with
|
| Status | Preview URL | Commit | Alias | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! | https://pr-120-charm.justin-tech.workers.dev | bf507e4 | pr-120 |
Wed, 17 Jun 2026 04:08:07 GMT |
Code Coverage OverviewLanguages: JavaScript JavaScript / code-coverage/vitestThe overall coverage in the branch remains at 22%, unchanged from the branch. Show a code coverage summary of the most impacted files.
Code Coverage is in Public Preview. Learn more and provide us with your feedback. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bf507e49e6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| event.waitUntil( | ||
| (async () => { | ||
| await persistLaunchContext({ |
There was a problem hiding this comment.
Persist launch context only for cold opens
This writes the launch marker before checking whether an existing window client will handle the click. For a warm notification tap, the existing client is navigated/focused below, but this cached marker is still consumed on the resulting or next bootstrap and records sable.app.launch_context as if the open was a cold notification launch. Persist it only when falling through to openWindow, or clear it when reusing an existing client.
Useful? React with 👍 / 👎.
| console.debug('[SW notificationclick] postMessage to existing client:', wc.url); | ||
| try { | ||
| if (pushNavigate && !pushRoomId && typeof wc.navigate === 'function') { | ||
| if (typeof wc.navigate === 'function') { |
There was a problem hiding this comment.
Keep invite clicks on the account-switching path
With this unconditional navigate, invite notifications with an existing window no longer post notificationClick to HandleNotificationClick, which is the path that calls setActiveSessionId(userId) before opening invites. The target URL only carries the user as ?uid=, and the inbox routes do not consume that parameter, so tapping an invite for a background account opens the currently active account's invite inbox instead of the notified account.
Useful? React with 👍 / 👎.
Description
Harden Charm's PWA push and resume recovery flow so notification-driven restores, cold launches, and long-idle resumes follow a single reliable path.
This PR:
/to/...deep-link path for both warm and cold flows/toentry, jump start/completion, resume triggers, and cold launch from notification clicksRelated to #91.
Builds on the earlier merged push/resume follow-ups in #68, #116, and #117.
Fixes #
Type of change
Checklist:
AI disclosure:
This PR was AI assisted for the implementation and test updates around PWA push/resume recovery. The changes restore lazy SW claiming on foreground resume, reconcile web push registration at startup, route room notification restores through
/to/:user/:room/:event?, add end-to-end restore telemetry, persist a notification-click launch marker for cold-launch classification, and add a manual QA matrix for warm resume, BFCache restore, long-idle reopen, and cold launch from notification taps.