bug(web,hub): duplicate Web Push notifications when Edge site and installed PWA are both enabled

[techotaku39]

Description

When HAPI is used both as a normal Microsoft Edge website and as an Edge-installed PWA on the same Windows 10 machine, a single session event can produce two identical Windows notifications.

The duplicate notifications appear under two separate Windows notification sources:

• hapi.techotaku39.top (via Microsoft Edge)
• HAPI (via Microsoft Edge)

Disabling either source stops one batch of the duplicate notifications.

Steps to Reproduce

1. Open HAPI in a normal Microsoft Edge tab.
2. Grant notification permission.
3. Install the same HAPI origin as an Edge PWA.
4. Open the installed PWA and grant notification permission.
5. Leave both contexts in the background.
6. Trigger a notification-producing event, such as Ready for input.
7. Open the Windows notification center.

Expected Behavior

One session event should produce one notification per logical device, while still allowing notifications to be delivered to separate physical devices.

Actual Behavior

The same event produces two identical notifications on the same Windows machine. The notifications are shown under separate Edge notification sources.

After disabling one of the sources, the duplicate notification batch no longer appears.

Environment

• OS: Windows 10
• Browser: Microsoft Edge
• Installation: HAPI used as both a normal website and an installed Edge PWA
• HAPI origin: hapi.techotaku39.top

Additional Investigation

The current implementation appears to:

1. Automatically register Web Push from both browser and PWA contexts.
2. Store multiple subscriptions under the same namespace when their endpoints differ.
3. Send each notification to every stored endpoint in that namespace.

This behavior is reasonable for supporting multiple physical devices, but the browser and installed PWA on the same machine are not identified as the same logical notification device. The notification tag also cannot deduplicate notifications across separate Edge application identities.

This suggests a Web Push subscription lifecycle or device-deduplication issue rather than an Edge rendering problem.

Requested Behavior

Please consider a subscription-management or device-identification strategy that:

• Preserves notifications on separate physical devices.
• Prevents duplicate notifications from the normal Edge website and the installed Edge PWA on the same device.
• Provides a way to inspect, disable, or remove individual Web Push subscriptions.
• Adds regression coverage for the browser-plus-PWA scenario.

Related Context

• bug(web): blurry HAPI icon in Windows Edge PWA notifications #1622 and fix(web): provide exact PWA icon sizes for Windows notifications #1625 concern Windows Edge PWA notification icons, not duplicate delivery.
• fix(web): reuse existing PWA window for notification clicks #1616 concerns notification-click window reuse, not duplicate delivery.
• fix(web): re-subscribe push subscriptions when VAPID keys change #1316 concerns stale subscriptions after VAPID key changes.

[github-actions]

Thanks for the detailed report. I can confirm that the current main implementation allows this behavior.

Every authenticated, non-Telegram browser context with Push API support automatically registers its own subscription. The hub identifies Web Push subscriptions only by namespace + endpoint, so two different Edge endpoints for the site and installed PWA are both retained. When no web client is visible, the hub sends the same payload to every endpoint in that namespace.

There is currently no logical-device identifier that could associate those two endpoints, and I did not find an API or UI for listing and managing individual Web Push subscriptions. The existing delete endpoint removes only a specified endpoint. I also did not find regression coverage for a site-plus-installed-PWA pair.

Relevant code:

• web/src/App.tsx:203 - automatically requests permission/subscribes authenticated Push-capable web contexts.
• web/src/hooks/usePushNotifications.ts:111 - reuses or creates the context subscription, then registers its endpoint with the hub.
• hub/src/store/index.ts:477 - stores subscriptions with uniqueness limited to namespace, endpoint.
• hub/src/push/pushService.ts:41 - loads every subscription for the namespace and sends to all of them.
• hub/src/web/routes/push.ts:25 - exposes subscribe and endpoint-specific unsubscribe operations; no list operation is defined here.

This supports treating the report as a Web Push subscription/device-deduplication gap. A fix will need to preserve separate physical-device delivery while defining how browser and installed-PWA endpoints can be grouped or individually managed.

---

HAPI Bot