Based on what I have observed while testing and this piece of code:
it seems like any event published while the connection was down is not lost, but en-queued. Which seems like a really sensible thing to do if one wanted no data loss.
However my scenario is slightly different, I expect some down times and my events are not essential, hence I’d like to be able just immediately get out of AppendToStreamAsync with an error and suffer some event loss (let the bickering begin…), rather than wait for the connection to be restored or the max connect attempts to be reached and then for my append to stream operation to fail (which I presume it is somehow related to StartOperationMessage operation) This is because, during the times where the connection is down (flaky hardware, network saturation, under powered machines, we have all that), I’m concerned I’ll be getting out of memory issues from growing the _operations queue or really just running out of threads (my publish operations are fire and forget). I think the out of memory can be tackled by setting the queue size in connection settings; could be that this protects against the threads issue too, I have not figured that out yet.
Regardless, the solution I have is keeping the state of the connection in my own object, managing it through the connection’s events Connected, Disconnected and Closed, and just checking that prior to calling AppendToStreamAsync.
I’m just wondering if there’s a better “out of the box” solution for achieving this so I don’t reinvent wheels?