merge: promote staging to v3 (F9 notif spam fix)#83
Merged
Conversation
…ing (#78) Background-delivered messages scheduled a fresh notification request per event, so iOS stacked one banner per message in the tray (same symptom as F9 — "push notifications spammed instead of updated"). Android was saved only by the channel-level group fallback. Pass a per-peer identifier (`anonmesh-msg-<srcHash>`) on scheduleNotificationAsync. On iOS this reuses the same UNNotificationRequest slot so a follow-up message replaces the unread banner instead of stacking; on Android same-identifier reuse updates the existing notification in place. Mirrors the single-id pattern already used by usePeerCountNotification. No new permissions or native config.
Contributor
There was a problem hiding this comment.
Pull request overview
Promotes the current staging integration tip to v3, primarily to deliver the F9 background notification spam fix by making per-sender message notifications update/replace instead of stacking.
Changes:
- Add a per-peer
identifierto message background notifications so subsequent messages from the same sender replace the existing tray entry. - Add inline documentation explaining the per-peer notification identifier behavior across iOS/Android.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
89
to
92
| Notifications.scheduleNotificationAsync({ | ||
| identifier: `anonmesh-msg-${srcHash}`, | ||
| content: { title: sender, body: 'new message', sound: true }, | ||
| trigger: null, |
| // on Android the channel already groups under 'messages'. | ||
| Notifications.scheduleNotificationAsync({ | ||
| identifier: `anonmesh-msg-${srcHash}`, | ||
| content: { title: sender, body: 'new message', sound: true }, |
…rruption (#84) Message notifications (useMessageNotifications.ts): Lock screen / Notification Center now show generic content only — `title: 'anonmesh'`, `body: 'New message'`. No sender hash, no preview. In-app banner (when the app is foregrounded) still surfaces the sender, since the user is already inside the app. Combined with the per-peer identifier from #78 and `interruptionLevel: 'passive'`, follow-up messages collapse silently into the existing tray entry instead of re-presenting the banner. Peer-count notification (usePeerCountNotification.ts): Split by platform. - iOS: schedule ONCE on 0↔peers transition; body is generic 'Mesh active'. Notification Center has no silent persistent surface, so every reschedule resurfaces the entry. The in-app indicator carries live counts; the tray entry just signals "mesh is on". - Android: live counts on the LOW-importance 'peer-status' channel. The channel handles silence, so updates flow without re-presenting. No native module changes, no permission changes — JS-only, ships via Metro hot-reload or any existing dev build.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Promotes
stagingtov3. Brings the F9 notification spam fix to users.This is a release-branch promotion PR. New convention going forward (per team-lead directive 2026-05-19):
staging→ review → merge.staging → v3promotion PRs roll integration tip to release.What lands in v3
mobile_app/hooks/useMessageNotifications.ts— per-peeridentifiercollapses tray notifications instead of stacking. iOS UNNotificationRequest reuse + Android NotificationManager.tag reuse. +5 LOC. MirrorsusePeerCountNotification(live in prod, no spam reports).What v3 already has that this PR preserves
Verification
dumpsys notificationconfirms identifier-collapse mechanism is live forusePeerCountNotificationon this device.Gated test (deferrable, low-risk)
Behavioral 2-device smoke (5-step checklist):
iOS verification deferred to TF window. Worst case if iOS quirk → identical to today's spam behavior, zero new failure mode.
Heads-up flagged in v3 (not introduced by this PR)
context/NetworkModeContext.tsx:110/112referencesbeaconRpcWaitbut L64 destructure readsbeaconBroadcastRpc. Pre-existing merge-resolution artifact from feat(mesh-rpc): migrate MeshRpcAdapter to beaconRpcWait link protocol #80/feat(mesh-rpc): beacon broadcast RPC + sendTransaction fix #81. Mesh adapter will fail at runtime whenmode === "mesh". ~3-LOC fix when picked up — happy to open a small follow-up..github/workflows/release-android.ymlhas been failing on every v3 push since 2026-05-16 at theBuild release APKstep. Effect: GitHub release tags don't get fresh APKs. Worth a separate look.