Warning is not an error #7130

Currently, bitcoind reports an error when it wants to warn the user (eg, when hitting an outdated version):

bitcoin-cli getinfo
{
    "version" : 110100,
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "balance" : 1.69743172,
    "blocks" : 385894,
    "timeoffset" : 0,
    "connections" : 8,
    "proxy" : "",
    "difficulty" : 72722780642.54718018,
    "testnet" : false,
    "keypoololdest" : 1423141169,
    "keypoolsize" : 10001,
    "unlocked_until" : 0,
    "paytxfee" : 0.00000000,
    "relayfee" : 0.00005000,
    "errors" : "Warning: This version is obsolete; upgrade required!"
}

Now, this is confusing. A warning is not an error. Warnings should be reported, but should not stop processing as errors do.

The problem with the current behavior is that it causes libraries to bail: common behavior is to check for the presence of errors in the result to report an error to the calling code. An example is python-bitcoinrpc: the library raises an exception, which interrupts the normal processing of the result. This happily breaks production systems due to a non-criticial warning.

Cleanest way would be to add a warnings field in the results. However, this would require all libs to be updated so that the warning is not silently swallowed but exposed to the user.

I agree that "errors" is maybe not the best choice there. But this should not break existing client libraries.

IIRC, the response should be something like (error within the response->result object): { "jsonrpc": "2.0", "result": { "version" : <v>, ..., "error" : "Warning...."}, "id": 1} which is a valid JSON RPC 2.0 response

In case of a real error, it will return (error object on top level): { "jsonrpc": "2.0", "result" : {}, "error": "Real-Error", "id": 1}

There is zero change that getinfo will be changed. It exists only for backward compatibility and will be deprecated at some point. See the comment here: https://github.com/bitcoin/bitcoin/blob/master/src/rpcmisc.cpp#L30

Note that there is no dedicated RPC call to get the errors yet. So this is an open opportunity to use another name to avoid this misunderstanding... or change the global error concept completely into something more fine-grained.

The problem with the current behavior is that it causes libraries to bail: common behavior is to check for the presence of errors in the result to report an error to the calling code.

Huh! No, that's not right. The 'errors' in the call result object does not interfere with JSONRPC's errors. You have a protocol level conflict in your handling somewhere if this is the case for you (ah, @jonasschnelli explains this in more detail)

Closing this issue though - it's not really a problem or bug, just a matter of using the API as it is defined.