Summary
Push notifications are back in 1.5.6, but each user only ends up with a single active subscription. Registering a second device overwrites the first one, so the earlier device stops receiving pushes.
Steps to Reproduce
- Run Split Pro 1.5.6 (e.g.
ossapps/splitpro:1.5.6).
- Sign in as the same user on browser/device A and opt in to notifications.
- Sign in as the same user on browser/device B and enable notifications there as well.
- Trigger a push (settle an expense, add a shared expense, etc.).
Current Behavior
Only the most recently registered device receives the notification. Inspecting the PushNotification table (prisma/schema.prisma:248) shows that the new subscription replaces the previous row, so the first endpoint disappears. This matches the current API flow in src/server/api/routers/user.ts:178, which effectively leaves us with one row per user.
Expected Behavior
Every device that successfully subscribes should keep its own push subscription so all of them receive notifications.
Proposed Changes
- Remove/adjust the unique constraint that limits
PushNotification to a single row per userId, and add the migration to drop it in production.
- Update the
updatePushNotification mutation so creating a new subscription never evicts the existing ones; keep the cleanup path on explicit unsubscribe.
- Double-check
sendExpensePushNotification still fans out to every subscription (it already uses findMany, so just make sure nothing else filters).
- Add regression coverage (API or integration) proving that registering a second device preserves the first subscription.
Additional Context
This came up while verifying push notifications on 1.5.6 in #445.
Summary
Push notifications are back in 1.5.6, but each user only ends up with a single active subscription. Registering a second device overwrites the first one, so the earlier device stops receiving pushes.
Steps to Reproduce
ossapps/splitpro:1.5.6).Current Behavior
Only the most recently registered device receives the notification. Inspecting the
PushNotificationtable (prisma/schema.prisma:248) shows that the new subscription replaces the previous row, so the first endpoint disappears. This matches the current API flow insrc/server/api/routers/user.ts:178, which effectively leaves us with one row per user.Expected Behavior
Every device that successfully subscribes should keep its own push subscription so all of them receive notifications.
Proposed Changes
PushNotificationto a single row peruserId, and add the migration to drop it in production.updatePushNotificationmutation so creating a new subscription never evicts the existing ones; keep the cleanup path on explicit unsubscribe.sendExpensePushNotificationstill fans out to every subscription (it already usesfindMany, so just make sure nothing else filters).Additional Context
This came up while verifying push notifications on 1.5.6 in #445.