Rework LiveActivity push stats: broadcasts as apnsLiveActivity, push-to-start as apnsPushToStart - #350
Rework LiveActivity push stats: broadcasts as apnsLiveActivity, push-to-start as apnsPushToStart#350JoaoDiasAbly wants to merge 1 commit into
Conversation
- push.notifications.*.apnsLiveActivity now counts broadcast issuance (was per-device push-to-start sends), staying out of the apns/total aggregates - add push.notifications.*.apnsPushToStart for the per-device push-to-start sends - drop push.apnsBroadcasts, superseded by the notifications entries
| "type": "number", | ||
| "inclusiveMinimum": 0, | ||
| "description": "Total number of successfully-delivered APNS Live Activity Push notifications." | ||
| "description": "Total number of successfully-issued APNS Live Activity broadcasts, the final broadcast sent by an end request included. Each broadcast is a single request to Apple that Apple fans out to every device subscribed to the broadcast channel (Ably has no per-device visibility), so this counts issuance, not deliveries, and is not included in the apns or total aggregates, which count per-device notifications." |
There was a problem hiding this comment.
not included in the apns or total aggregates, which count per-device notifications
Why make this distinction?
There was a problem hiding this comment.
Because I think otherwise we'd make the existing total inaccurate:
- each time we increment the existing total it means "one device got a push"
- each time we increment this it means "we sent out a broadcast"
Since the fanout for these broadcast is at the Apple's side and as stated in ADR-159 we don't have visibility into those broadcasts, we can't accurately say how many devices received it, which would be the correct value to increment in the existing total. So I think it makes sense to track how many broadcasts we issued and I think it's a complete different stat.
Wdyt?
There was a problem hiding this comment.
each time we increment the existing total it means "one device got a push"
I think that's one way to interpret it, but "device" is not mentioned in either the stat name or the description, and I think it's actually more confusing that total isn't the total of the individually labelled stats.
If we want "device push" and "broadcast push" to be separated, I think we should make that more explicit (e.g. put the LiveActivity stats under push.broadcasts.xxx), but to be honest I think these legacy stats are already pretty confusing, and so perhaps do what you think is reasonable here and we should do this better in the (as yet unreleased) labelled stats.
There was a problem hiding this comment.
"device" is not mentioned in either the stat name or the description
fair, I can adjust the description if you think it's worth it
to be honest I think these legacy stats are already pretty confusing, and so perhaps do what you think is reasonable here and we should do this better in the (as yet unreleased) labelled stats.
yeah I would prefer to not change things again and go "against" the legacy stats structure - do you agree we leave it like this now, which I think works fine even though it might still not be too obvious to the user but I don't think we can do better while adhering to the legacy stats structure - and try to improve later with labelled stats?
2 participants
Follow-up to #349 from the stats discussion on ably/realtime#8527 (approval comments on
stats.go): broadcasts are the third APNs notification type and belong underpush.notifications.*, per-device push-to-start sends get their own label, and the standalone broadcast counter goes away.push.notifications.*.apnsLiveActivitynow documents broadcast issuance: a single request Apple fans out to every subscribed device, the end request's final broadcast included; excluded from theapns/totalaggregates, which count per-device sendspush.notifications.*.apnsPushToStartentries for the per-device push-to-start sends (the previousapnsLiveActivitywording)push.apnsBroadcastsremoved, superseded by the entries above; request-level accounting already exists via api-request statsNo
versions.jsonbump, following #349. The keys changed here have only been emitted since realtime#8527 (2026-07-17) and the first customer trial hasn't started, so reshaping is still cheap.Merge before ably/realtime#8560, which switches the emitters and bumps its submodule to pick this up.