Summary
When hookdeck listen cannot establish its websocket, it reports that it gave up but not why:
Could not connect. Terminating after 10 failed attempts to establish a connection.
The reason exists — the dial error is right there in connect() — but it is logged at debug, so at the default log level the user learns nothing about whether it was DNS, a refused connection, a proxy, a TLS failure, or a rejected session.
Why it matters
This is the other half of #376. That issue covered the CLI not saying when it had connected; this is the CLI not saying why it had not. A caller who sees neither cannot tell a healthy tunnel from a broken one — which is how a working connection came to be reported as a failure in the first place.
Reproduction
Point the CLI at a websocket endpoint with nothing listening:
hookdeck listen 3000 <source> --ws-base ws://localhost:39999
Before: 10 attempts over ~20s, then the message above with no cause.
After the fix:
Could not connect. Terminating after 10 failed attempts to establish a
connection. Last error: dial tcp [::1]:39999: connect: connection refused
Fix
Keep the last connect error on the websocket client and include it in the terminating message. --log-level debug should not be the only way to find out what happened.
Summary
When
hookdeck listencannot establish its websocket, it reports that it gave up but not why:The reason exists — the dial error is right there in
connect()— but it is logged atdebug, so at the default log level the user learns nothing about whether it was DNS, a refused connection, a proxy, a TLS failure, or a rejected session.Why it matters
This is the other half of #376. That issue covered the CLI not saying when it had connected; this is the CLI not saying why it had not. A caller who sees neither cannot tell a healthy tunnel from a broken one — which is how a working connection came to be reported as a failure in the first place.
Reproduction
Point the CLI at a websocket endpoint with nothing listening:
Before: 10 attempts over ~20s, then the message above with no cause.
After the fix:
Fix
Keep the last connect error on the websocket client and include it in the terminating message.
--log-level debugshould not be the only way to find out what happened.