Stream: subscriptions
Topic: R4 subscription-event-count
Weiyu Zhang (Jan 23 2020 at 23:15):
The subscription-event-count extension indicates the number of unique events that have triggered notification attempts on this Subscription PRIOR to the current notification being sent.
In the case of a handshake, this count will always be zero (0).
In the case of a heartbeat notification, this count will be the same as the last notification and will not be incremented due to the heartbeat notification.
In the case of event notifications, the event count will be incremented by the number of notifications contained within this bundle (often a single notification, though servers may choose to batch notifications within a short time interval).
In the case of an event notification that cannot be delivered (e.g., because a client endpoint is offline), the server MAY retry delivery but does not increment the event count; the count represents unique events, not unique delivery attempts.
I think I'm reading too much into this, but should subscription-event-count be:
- the total number of events, inclusive of events in the current bundle (i.e. the running total of all bundle-event-count values, including the current bundle that subscription-event-count is being calculated for)
- the total number of events, exclusive of events in the current bundle (i.e. the total of all bundle-event-count values sent before this bundle)
The first line of the description strongly implies the latter (the exclusive definition), but wouldn't an event notification + heartbeat notification sequence violate the "In the case of a heartbeat notification, this count will be the same as the last notification" requirement?
Last updated: Apr 12 2022 at 19:14 UTC
