Lukas Maywald

We already found that when a modbus command function (like `read_input_registers()`) is called on the client, while it is still in the `connecting` state, the modbus callback doesnt get deleted....

Yes, I can confirm that we are using the 1.3.1 release in a Debian based Docker Container on the [Torizon OS](https://www.toradex.com/de/operating-systems/torizon-core) Platform. We are using the `aarch64-unknown-linux-gnu` version of the...

[torizon/debian:3.2.1-bookworm](https://hub.docker.com/layers/torizon/debian/3.2.1-bookworm/images/sha256-076a01794b5b3a1fbef23ff5729745ff867cc9aaec82488a04214d7fd58863ae?context=explore)

Yes, I have now seen that this part of the queue does work properly. The `unique_ptr` does get deleted once the connection fails or succeeds. I think our problem might...

> That said, I think the issue is that we're spawning requests faster than the tasks are being failed. Yeah, that might be it. In the worst case, we will...

> A) Schedule your polls on some timer in the main C++ thread Yes, thats what we did. Thats why the queue piled up pretty quickly. We have already tried...

Great work! We really appreciate your support for the library. We encountered one last thing we would like to discuss. With the current implementation we never know how full the...

there actually does seem to be a TCP RST frame.. however the destination port seems weird, i cant find this port again anywhere in the trace but yes, this seems...

another thing i have noticed is that rodbus does not report a connectivity problem when the ethernet connection is interrupted  here rodbus only reports single timeouts for each message...

yes, i interrupted the connection by pulling the ethernet cable in this scenario rodbus does not report any changes about the `ClientState` via the `PrintingClientStateListener` and the request callbacks only...