Reduce RPC error log to debug when domain-level RPC service returns an error

[SWvheerden]

 // comms/core/src/protocol/rpc/server/mod.rs:6662022-08-31 10:25:53.657760000 [comms::rpc] [Thread:6100299776] DEBUG (stream_id: 25, peer: 783939753066407bf8d1ba04af, protocol: t/bnwallet/1) RPC request completed in 378µs
 // comms/core/src/protocol/rpc/server/mod.rs:6202022-08-31 10:25:53.667513000 [comms::rpc] [Thread:6102446080] ERROR stream_id: 9, peer: 783939753066407bf8d1ba04af, protocol: t/bnwallet/1 Service returned an error: NotFound: Header not found at height 2663
 // comms/core/src/protocol/rpc/server/mod.rs:6202022-08-31 10:25:53.671530000 [comms::rpc] [Thread:6106738688] ERROR stream_id: 15, peer: 783939753066407bf8d1ba04af, protocol: t/bnwallet/1 Service returned an error: NotFound: Header not found at height 2664

These error messages should not be errors.
These are caused by a wallet requesting bad information

[stringhandler]

To add some context: When an RPC errors, it should not show an error. Perhaps warn is more reasonable?

[SWvheerden]

I think we should try and look more carefully at RPC errors.
If we receive an actual RPC error, then yes, we should log the error.
But in this case a WARN or perhaps a Debug is perfectly fine.

[CjS77]

I've written about the log level philosophy before. Maybe we should include it in the docs / RFC somewhere.

INFO and above is what an average (non-dev) client / user will be reading. You should ask yourself whether a user would be interested in those messages. Basically, if they're recoverable errors, they just go to debug.

ERRORs are things that are going to stop the app, break the app in some way, or worse, e.g. of data corruption.
WARNings are errors the user should know about, but aren't show-stoppers.
INFO are short updates, like found new block, mined a block, tx received, etc.

Everything else is DEBUG (interesting for devs) or TRACE (really detailed info, and used sparingly)

[CjS77]

So using this philosophy, I'd say they should be DEBUG most likely.