A push token may be claimed by one device row, not every past sign-in

FixSecurityService
Ya
26 Agosti 2026, 06:05 UTC
Mwandishi
Kamo
Ahadi ya
2f99cd0

Companion to MediaService 8a809b3, which stopped members getting the same chat message three-plus times on their phone. That change made dispatch collapse duplicate destinations; this one stops the duplicates being created. device/register mints a new user_device_tokens row unconditionally, so signing in again on the same handset produces a brand-new device_token_id. The push registration is unique on (device_token_id, org_id, push_kind) — NOT on the token — while FCM/APNs keep handing back the SAME token for that install. So every sign-in left one more registration row pointing at the one phone, and they never expired: FcmSender only prunes on UNREGISTERED, which FCM returns for dead tokens, never for surplus rows naming a live one. Production had 21 rows resolving to 2 real devices, one member holding 5 rows for 1 token. A push token addresses exactly one app install, so when it is presented under the current device row, every other row claiming it is stale by definition and is deleted. Distinct devices and APNS_VOIP rows are matched on kind as well as token, so they are never collapsed into each other. The delete is best-effort: failing it costs a duplicate row, not a failed registration, and dispatch-side collapsing already covers that case. Existing rows heal on each device's next push-token registration, which happens on foreground.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei