I’m not sure why the connection becomes disconnected. In the tests I’ve done, I could have multiple processes running on local machine subscribing to various streams and then one of them disconnects, while another doesn’t even if subscribed to the same stream. I can restart the subscription upon dropping, but trying to avoid this or at least deal with it at a lower level.
It looks like it is caused by: hearbeat timeout -> close socket -> close connection -> drop subscription
The issue is that the connection reconnects, but the subscription doesn’t. Do you think it would be acceptable to add such a mechanism on top of the client? Or do you think it is better to crash to whole process and restart?
Also, in this case I had a local EventStore instance running with to processes with one subscription each. The default heartbeat timeout is 1500ms. Not sure why it would timeout. Would you advise increasing the timeout?
Where are you registering your subscription? The best place to do this is likely when handling the connected event from the client - then they will resubscribe on reconnection.
There is a place where I handle the dropped event, at which point I could queue up a re-subscribe. Can I attempt a re-subscribe right after the dropped event? Or can I only do it after a successful reconnect?
Did you figure out how client disconnect should be handled? I’m having the same problem with SubscribeToAll which then disconnect for some reason which I can’t figure out and I stop receiving events.