Any ETA?

Hopefully this week alraedy. I refactored a lot in session handling the last days because this was strange and broken and made no sense anymore as I noticed that our controller did not even received "close session" calls ... soooo ... Right now trying to verify anything. And part of this is much more stuff, especially for controller, but also device.

Re

I think this should emit an error event which crashes the program if unhandled.

.. I think now. Device side wise this is a normel case that e.g. the controller could have gone offline and we still tryto send. so the case is handled now exatly as it should ...

That sounds like good news!

so the case is handled now exatly as it should ...

I would argue about that. I think I didn't make it clear: retry is okay and there's no need for an error for retry, but it should either keep retrying or emit an error.

Currently, it cancels the subscription silently and would probably leave the host process hanging there doing nothing, unless the lib user knows this specific behavior and handles it correctly (but usually a random lib user would not know that much information, so if retry is limited to 3 times, crash unless handled sounds better to me).

but it should either keep retrying or emit an error.

He will end the subscription (session) and this fact will not notified 8with my next changes) ... it is then a change in connected sessions, and so you will know which vendor/controller is still connected or not. I would try it that way.

In fact also these "3 retries" is kind of my personal invention. There is no definition at all i the specs how to handle this case, so I decided to do that that way.

Especially all cases where this could happen ( controller offline, network offline or has problems or such) end anyway in the case that controller reconnects.

But yes ... also my next change there will make it more specific and throw error in case it is a different error then a resubmission one