Question: How should correlationID be handled when event subscriptions/property observations overlap?

[benfrancis]

From #31:

@benfrancis wrote:

Just to note we also need to consider the scenario of overlapping subscriptions between subscribeEvent & subscribeAllEvents or observeProperty & observeAllProperties?

E.g.

1. Consumer sends subscribeAllEvents with messageID "1"
2. Consumer sends subscribeEvent with event name "foo" and messageID "2"
3. Thing sends event message with event name "foo" and correlationID "2"
4. Thing sends event message with event name "bar" and correlationID "1"
5. Consumer sends unsubscribeEvent with event name "foo"
6. Thing no longer sends event messages with event name "foo" even though the Consumer separately sent a subscribeAllEvents message
7. Consumer sends unsubscribeEvent with event name "bar"
8. Thing no longer sends event messages with event name "bar" but may continue to send event messages with the event name "baz"

@RobWin wrote:

That's indeed a good question. I haven't implemented subscribeAllEvents and didn't come across this issue yet.
It's tricky to decide what should happen if a consumer sends subscribeAllEvents and then subscribeEvent with event name "foo" and unsubscribeEvent with event name "foo".

[hspaay]

Based on proposal #42...

Yeah I ran into this as well. It is possible that a consumer sends both subscribeallevents and subscribeevent. Same goes for observeproperty.

Option 1: Treat them separately: Multiple subscriptions means multiple events. Receiving multiple events could signal a bug in the consumer.

Option 2: Subscribeallevents overrides everything else. When used all subscribeevent requests are replaced. When unsubscribeallevents is invoked, no subscriptions are left.

Option 3: Follow mqtt's behavior. ("When using wildcards in subscriptions, it's possible for subscriptions to overlap, meaning a published message might match multiple filters. In such cases, the server must deliver the message to the client respecting the maximum QoS of all the matching subscriptions.")

For any option, ignore the correlationID in the notification as it does not identify the subscription. The subscription is identified by the event/property name. (note I changed my mind on this as I have suggested using correlationID for tracking subscriptions in the past. Separation of concerns suggests this is a bad idea)

My personal preference is option 2 as it is easier to implement and we don't have QoS to worry about.

[benfrancis]

Option 2: Subscribeallevents overrides everything else. When used all subscribeevent requests are replaced. When unsubscribeallevents is invoked, no subscriptions are left.
...
My personal preference is option 2 as it is easier to implement and we don't have QoS to worry about.

I agree it makes sense if a subscribeallevents subscription replaces a subscribeevent subscription.

What if a subscribeevent operation comes after a subscribeallevents operation? Should it be ignored since the Consumer is already subscribed to all events?

What if an unsubscribeevent "foo" operation comes after a subscribeallevents operation which comes after a subscribeevent "foo" operation? Should the subscribeevent operation be ignored, and the Consumer continues to be notified about all events except "foo"?