Verify push registration refresh on silent notifications

[tabmail-kmyi]

Goal

Verify when the iOS app refreshes its push registration and whether a received silent notification should trigger the same refresh path.

Acceptance criteria

• Document the current foreground and silent-notification behavior.
• Confirm that reopening or foregrounding the app refreshes every active account registration.
• Determine whether silent notifications can safely refresh a missing or stale registration.
• If needed, add the smallest retry/resubscription trigger and focused tests.

[tabmail-kmyi]

Discussion required

Current behavior is already self-healing on foreground: SyncScheduler.startForegroundPolling() calls PushNotificationService.subscribeAllAccounts(), which refreshes provider subscriptions and each active account's device route. APNs token delivery also refreshes the device registration and every active per-account route. The silent-push handler performs sync only; it does not refresh registrations.

A concrete, current cross-account opportunity exists. On one device, account A has a working per-account route while account B's earlier per-account registration failed. A silent delivery for A can wake the app, but B stays unregistered until a successful foreground pass. Refreshing all active account routes during that wake could repair B without prompting for consent or re-subscribing providers.

This is not a self-repair path for a completely missing route: no route means no silent push can wake that device. It also cannot repair the distinct multi-device partial-route case when that device receives no notification at all.

A behavior change needs an explicit policy for the tradeoff: registration work on every delivered silent notification versus a bounded throttle/deadline policy. Background pushes are low priority, can be coalesced or throttled, and have limited runtime, so adding uncontrolled network registration to the existing sync window risks the delivery mechanism it is intended to help.

Decision options:

• Keep foreground-only registration refresh; accept the bounded gap.
• Permit an opportunistic silent-wake refresh with an explicitly chosen per-process or durable throttle and a bounded network budget.
• Add server-side route-health signaling/protocol support to request repair only when needed.

No client re-consent flow, PR, or implementation is proposed here.

[tabmail-kmyi]

Re-triaged 2026-09-03 under the scale-up lens (the IMAP IDLE droplet fleet grows from one droplet to many; rotations and deploys become frequent): priority: P4 → priority: P2.

Raised as a policy decision (throttle/deadline, or reject), not as a go to implement. Foreground already fans out one worker round-trip per active account in parallel (PushNotificationService.subscribeAllAccounts, withTaskGroup) plus device registration and a consent check, with no time-based throttle, inside SyncScheduler's isStartupInFlight herd gate; adding the same fan-out to every silent delivery is self-amplifying at fleet scale.

[tabmail-kmyi]

Re-triaged under the new P0–P5 priority scheme (2026-09-04): P2 → P4 — enhancement proposal that needs a throttle/budget policy decision; foreground repair already exists.