I quickly tested it and it worked fine for me 🥳 The only downside i see is that we still lose the information why it failed

The only downside i see is that we still lose the information why it failed

Isn't that logged?

hmm, I see, the timeout can have different reasons and in addition the Acceptor and endpoint are created in the constructor of the server. Would make this ticket bigger.

Did you written your answer on purpose as edit on my comment? 😆

I mean i think this fix already brings value the way it is now but to fully fix it it probably should log the errors that happen.

Did you written your answer on purpose as edit on my comment? 😆
No, I was in a hurry.

I mean i think this fix already brings value the way it is now but to fully fix it it probably should log the errors that happen.
I agree, I was thinking about a separate PR for that to keep changes in this one simple.

Invalid address strings are now logged, so mission complete. :)

I found another case 🙈 where if the port is already used we also just see a timeout:

(2024-11-26 08:10:18) [INFO    ] Before wait
(2024-11-26 08:10:21) [INFO    ] After wait
(2024-11-26 08:10:21) [INFO    ] Timeout

But im not sure if we can check for that, and this version is already way better than before 🥳

I found another case 🙈 where if the port is already used we also just see a timeout:

(2024-11-26 08:10:18) [INFO    ] Before wait
(2024-11-26 08:10:21) [INFO    ] After wait
(2024-11-26 08:10:21) [INFO    ] Timeout

But im not sure if we can check for that, and this version is already way better than before 🥳

This has to be handled inside of the server, I would propose to handle in a different issue - or maybe there are already some for this.