Confirmation when unsubscribed from a channel

[evan-coygo]

The problem

1. There's no way to confirm when an unsubscribe is completed
2. After making the unsubscribe call it's not possible to keep receiving any updates from that channel until the unsubscribe is completed, you just immediately stop receiving updates

Explanation

Currently once sending an unsubscribe message you're not informed if/when it unsubscribed successfully, and your subscription is immediately removed from the map of subscriptions, i.e. _level2UpdateSubs. It would be helpful to add some type of indicator that an unsubscribe was successful for a channel if the exchange supports it, and to be able to keep receiving messages until the unsubscribe is successful.

Particularly it would help when validating order books and the sequenceId is shared across channels since you need to know when you can stop listening for events for a channel.

This could be done a few different ways so I've started a discussion here first before creating an issue. I imagine this would probably involve either changing an existing API or adding a new one.

[bmancini55]

Great topic, thanks for submitting this discussion!

There's no way to confirm when an unsubscribe is completed

There is a large gap in the library surrounding subscribe/unsubscribe, on the subscribe side I see this manifesting a myriad of issues, to name a few:

1. There is no actual indication that a subscription succeeded. We rely on throttling logic in many clients to ensure we are in compliance with the constraints of an API, but we don't ever validate that. Exchanges treat violations in various ways, some just silently fail, others provide feedback. The net result is that you may have successfully subscribe to X/Y markets, but you won't ever know!
2. Subscribing to a market that doesn't exist may or may not generate an error, ideally you'd want the caller to know that the market they subscribe to is not actually valid.
3. Upon a reconnection event, subscriptions should resolve, but again we don't know. This can be particularly problematic for multi-socket clients that may initiate a bunch of socket connections.

After making the unsubscribe call it's not possible to keep receiving any updates from that channel until the unsubscribe is completed, you just immediately stop receiving updates

The unsubscribe use case you suggested is pretty interesting and I think we can resolve that. As you mentioned, unsubscribe is treated as a synchronous operation from the client's perspective. To make it async, the client needs to be aware of whether it supports unsubscribe confirmations. Resolving this add some additional complexity as we introduce some intermediary state. Right now it's only subscribed/unsubscribed, this transition to subscribed/unsubscribing/unsubscribed. So we need to consider state transitions for the unsubscribing state.

Perhaps a bigger issue is that many exchanges don't provide a confirmation message for sub/unsub. For these we should just avoid this complexity and make the clients treat sub/unsub as synchronous processes.

This could be done a few different ways so I've started a discussion here first before creating an issue. I imagine this would probably involve either changing an existing API or adding a new one.

Indeed! I guess the best place to start is where I want things to end up eventually, then we can figure out a solution to get there.

The architecture I want to get to is treating subscriptions as state machines. As a type they would contain the subscription details: market, type, arguments. Subscription will be scheduled by the client and assigned to a transport. Once the transport is available, the subscription payload is sent along the transport and is activating. At this point messages will arrive for the subscription hopefully. If it supports confirmations, it transitions to active (or immediately after the sub message is sent if confs aren't supported).

If the socket disconnects, the subscription becomes unassigned by the client and and waits for an available transport before going through the subscription state changes again.

With unsubscribe, we could just transition to an unsubscribing state when the user calls unsub. This sends the message on the transport. Once a confirmation (or immediately after if confs aren't supported) we transition to unsubscribed. The cool thing here is that because we have subscription state we can don't need to remove them from the maps. We can do clean up of inactive subscriptions at a future point in time.