Repository navigation
Lower logging level of an error #481
Description
Line 803 in edb0560
In our dev environment, where regtest is used, this log line spams the log outputs with an error logging level, despite being completely harmless and unimportant.
Good opportunity to discuss my pet peeve: "error logging level" is a misnomer, and tragically it compels developers to log everything that looks like an "error" with "error logging level".
Since log levels are supposed to be ... well... levels, they come with an increased severity/importance. In most higher level software most "errors" are completely unimportant and expected, and do not deserve "error logging level". I generally recommend not using the name "error level" at all, or internally rename it to a "fault", "severe" or "important", just to remind developers "error" != "error logging level".
- tracing - for debugging what the program is doing, trying to trace which code paths were taken
- debug - for normal debugging why something is not working
- info - for messages that end user might want to know, which are not problems
- warning - for things that the user should check on when they notice them, as they might be problems
- error (aka important) - for things the is a clear sign the app is malfunctioning and needs urgent attention
- critical (if distinct from previous one, when available in certain logging frameworks) - basically panic that shut down the app
Activity
tnull commentedon Mar 13, 2025
No, it's not 'completely harmless and unimportant'. Prolonged failure to update fee rates can have severe consequences in Lightning, for example leading to feerate disagreements with the counterparty and force-closures. So periodically retrieving current fee rates is vital for the correct operation of a Lightning node, which is why we log this as error, and even enforce a successful fee rate cache update on startup. If this is spamming your logs, you need to figure out why it fails and fix your chain source.
Thank you for the explainer on log levels.
dpc commentedon Mar 13, 2025
Prolonged is the keyword. A single failure is 'completely harmless and unimportant'.
An error could be printed when the fee rates are stale not every time the call failed. Otherwise every brief transient error lead to error level logs, which is operationally exhausting.
If someone wants to e.g. get a text message whenever their production services need attention, doing it on log level basis is a natural approach. But for that to work well, messages that are printed at highest logging levels need to be actually important, not just "maybe, kind of in the area that is important".
Ayoazeez26 commentedon Oct 7, 2026
I'm hitting this on a fresh regtest setup (ldk-server with a Polar bitcoin backend). On every poll,
Failed to retrieve fee rate estimates: bitcoind RPC error: invalid data: ["Insufficient data or no feerate found"]. Falling back to default of 1 sat/vbis logged at ERROR. #760 moved the related INFO logs to DEBUG but didn't change this one.I understand why prolonged fee rate failures warrant ERROR on mainnet, and the bitcoind backend handles that strictly (ERROR +
Err(FeerateEstimationUpdateFailed)). On regtest/signet, though, it deliberately falls back to 1 sat/vB and completes the update, yet still logs ERROR per target.The other backends treat the same "no estimate available" case as expected: both Esplora and Electrum clamp to 1 sat/vB and log only at TRACE. So bitcoind is currently the only backend that reports this fallback as an error.
Would it make sense to log the regtest/signet (and possibly testnet) fallback in the bitcoind backend at WARN instead, leaving mainnet behaviour unchanged, so it's consistent with the other chain sources? Happy open a PR with the fix if that sounds reasonable.