sebadob

I don't know if this is related, but I am losing Consumers with the `async_nats` currently too (tested 0.18.0 and 0.17.0 so far). After some time (different timings so far)...

I had 2 pods with the test app running last night. What works for now as a not_so_efficient_workaround is the following (stripped down version for the example): ```rust async fn...

@Jarema I will implement v0.19 in my clients and have a look, if I still get into the situation, where I get an error in the `select!` branch where the...

First findings from my testing are, that it looks very promising. I left the `select!` branch in to see if my own error is logged or the new debug logs....

I removed my manual `select!` branches for error checking, had all left over test cases running all day long and did not have any issues. The problem is solved with...

Update - Not so good news: I had all applications running for ~24hours now and when I wanted to do another round of quick testing this morning, the consumers were...

Ahh okay, I did not know about the Nats issues. I will look forward to the new release. What exactly happens, when the `inactive_threshold` will be exceeded? I will give...

Perfect, thank you very much. I am using ephemeral consumers, since I will have quite a few IoT clients which change dynamically. I will try the `inactive_threshold`.

Update from my side: With Nats-Server 2.9 + `inactive_threshold` + changing to a durable consumer solved all leftover issues for me. Thank you very much @Jarema

For anyone who still has this problem, I stumbled across the same when I now just started a new project with postgres 15, which changed the default behavior for the...