Issue with SubscribeToStreamFrom and a null liveProcessingStarted

Probably pilot error here, but I am having a strange problem using SubscribeToStreamFrom.

My code:








So I didn’t include liveProcessingStarted (5th argument), but subscriptionDroppedForCatchUpAction is not fired when this is null.

I tested it by including a definition for liveProcessingStarted and my dropped event starts getting fired.

Is this the intended behaviour?

For me, the interface implies you can choose which ones to include, rather than a dependency on live being passed in.

Thanks in advance.

How are you testing this?
You are correct in your assumption that optional arguments are not required.


Setup the SubscribeToStreamFrom and kill the Event Store node and you should get the subscription dropped handler called.

I built a test harness as my service was showing some strange behaviour.

When I include the liveProcessingStarted , the event ordering is as follows:

eventAppearedFromCatchUpAction (for n messages)



So, my understanding is, subscriptionDroppedForCatchUpAction gets called in a successful flow, not just for errors or the connection being forcibly closed.

subscriptionDropped has a reason and exception associated with it,
what reason/exception are you being given?


I tried running this from my service and test harness, and both times the Subscription Dropped event is no longer being fired.

The only difference is, I was running without the debugger to get hold of the subscription dropped reason / exception.

It may well have been a timing issue since I was debugging, and it was my connection being dropped.

Sounds like a non issue.

Thanks for the quick response.

When debugging you have to be careful about heartbeat timeouts. The
debugger stops all threads and causes the connection to be dropped. In
order to debug you need to set much higher your heartbeat timeouts on
both the client and the server.