bitcoin-cli: Make error message less confusing #9265

Sorry for the churn on this, but the current message (introduced in #9073) isn't acceptable:

$ src/bitcoin-cli getinfo
rpc: couldn't connect to server
(make sure server is running and you are connecting to the correct RPC port: -1 unknown)

Putting the error code after the words "RPC port" made me wonder whether there was a port configuration issue.

This changes it to:

$ src/bitcoin-cli getinfo
error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)

Somehow, I'd expect to see the string "Connection refused" somewhere in the output, but this makes it a bit clearer, yes:

$ ./bitcoin-master/src/bitcoin-cli
error: couldn't connect to server
(make sure server is running and you are connecting to the correct RPC port: -1 unknown)
$ ./bitcoin-9265/src/bitcoin-cli
error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)
$

ACK fe37fbe

I'm not aware of any way of getting the underlying error OS error code from libevent. The one shown is libevent http error and every network layer error will basically get -1. But feel free to suggest a way.

The other alternative would be to revert #9073 and leave it at that.

This prints the message I want to see:

diff --git a/src/bitcoin-cli.cpp b/src/bitcoin-cli.cpp
index b272640..04157c0 100644
--- a/src/bitcoin-cli.cpp
+++ b/src/bitcoin-cli.cpp
@@ -19,6 +19,7 @@
 
 #include <event2/event.h>
 #include <event2/http.h>
+#include <event2/http_struct.h>
 #include <event2/buffer.h>
 #include <event2/keyvalq_struct.h>
 
@@ -164,6 +165,9 @@ static void http_request_done(struct evhttp_request *req, void *ctx)
         return;
     }
 
+    if (req->response_code == 0)
+        fprintf(stderr, "PJ: Connection refused!\n");
+    
     reply->status = evhttp_request_get_response_code(req);
 
     struct evbuffer *buf = evhttp_request_get_input_buffer(req);

But that's cheating - you have no idea at that point whether the underlying error was really "connection refused". It could just as well be some other network-layer error. Printing a potentially false error would be worse for troubleshooting than not doing anything.

utACK fe37fbe

@laanwj Right. libevent hides the exact issue from us.

utACK fe37fbe606f099e81c693fae248c23c8f8fd5735

Bonjour