Eventstore: SubscriptionDropped handler is lost after reconnect

[misiektg86]

SubscriptionDropped handler in the EventStoreStreamCatchUpSubscription is not working when EventStore reconnected.

[gregoryyoung]

Can you be a bit more specific?

[misiektg86]

Sure. The Connection.SubscribeToStreamFrom method has parameter called subscriptionDropped which is of type Action<EventStoreCatchUpSubscription, SubscriptionDropReason, Exception>. The problem is that when you lost connection to EventStore but finally you reconnect again then this handler is not invoked anymore, even if you lose connection again and reconnect. Summarizing it seems to work only until first connection lost

[gregoryyoung]

Maybe you can provide a test showing the behaviour you are seeing? From a cursory look:

https://github.com/EventStore/EventStore/blob/release-v4.0.0/src/EventStore.ClientAPI/EventStoreCatchUpSubscription.cs#L355 and the handler is readonly https://github.com/EventStore/EventStore/blob/release-v4.0.0/src/EventStore.ClientAPI/EventStoreCatchUpSubscription.cs#L53 so I don't see a reason why it would not be called a second time.

[misiektg86]

What about https://github.com/EventStore/EventStore/blob/release-v4.0.0/src/EventStore.ClientAPI/EventStoreCatchUpSubscription.cs#L346 ? It looks that it is not set to 0 again

[gregoryyoung]

Are you expecting the same subscription to automatically resubscribe? I don't believe it does this, on dropped you should resubscribe if you want to. Are you receiving events over your subscription at this point?

[misiektg86]

Yes, I still receive events and this is why I was thinking that this is a bug

[hayley-jean]

I can reproduce this behaviour as well.

Catchup subscriptions resubscribe when they lose connection (they're the only subscription that do this) which explains why you still get events.

In previous issues that have arisen because of this behaviour, such as #929, we have recommended that people call Stop() on the subscription in their SubscriptionDropped handler and resubscribe.

[misiektg86]

I did the same(resubscription) but in Connected handler but this in turn caused #861 :( I will try what you recommend.

[alexeyzimarev]

CatchUpSubscription also stops the actual subscription when going over the processing queue limit (slow handler) and starts reading historic events. After it has read historic events, it starts the subscription again. So, it resubscribes. It works fine. The only issue is that the drop handler is only called once because of the check done at https://github.com/EventStore/EventStore/blob/release-v4.0.0/src/EventStore.ClientAPI/EventStoreCatchUpSubscription.cs#L346

[misiektg86]

Personally it would be better for me if it resubscribe automatically. Then I could just react in this dropped handler when I need. Now I have some awkward code I don't like and I don't feel comfortable with which resubscribes on few drop reasons.

[Narvalex]

Any update on this?

[oletolshave]

I have just been bit by this. It took a while to troubleshoot, because it happens fairly rarely and after a restart the subscriptions seems to be working. But the first exception after a restart causes the subscription to die almost silently and the difference in time from the restart to the subscription dying was such a long time, that the restart was not immediately suspected as the root cause.

[jageall]

Subscriptions no longer automatically subscribe when the connection drops, instead the subscription dropped method is called and the consumer is expected to resubscribe in the dropped handler. This eliminates many edge cases and race conditions that led to unpredictable behaviour. including losing the dropped handler, receiving events more than once etc. #2367