log: exempt all category-specific logs from ratelimiting when running with debug #34018

1. 
   stickies-v commented at 3:53 pm on December 5, 2025: contributor

   Previously, running with -debug=<category> would exempt the debug and trace log messages in that category from rate limiting, but not the info/warning/error category-specific messages (which are rare). This is unintuitive and unnecessary.

   When users run with -debug, we already assume they are power users and that they will have significantly higher log volumes, so there is no real benefit from suppressing info log messages in that category.

   Fix this by applying ratelimiting exceptions from -debug=<category> to all logs in that category.

   Also updates net_processing to log new peer connections with NET category. This way, when running with -debug=net, the log message (which can be frequent) will not get ratelimited when the user explicitly opts into getting higher log volumes for net.

   Introduces slight behaviour change by prefixing the log message with [net:info].

   Alternative to #34008

2. DrahtBot added the label Utils/log/libs on Dec 5, 2025
3. 
   DrahtBot commented at 3:53 pm on December 5, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34018.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

   Conflicts

   Reviewers, this pull request conflicts with the following ones:

   • #34008 (log: don’t rate-limit “new peer” with -debug=net by 0xB10C)

   If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

4. stickies-v renamed this:
   log: exempt all category-specific logs from ratelimiting
   log: exempt all category-specific logs from ratelimiting when running with debug
   on Dec 5, 2025
5. DrahtBot added the label Needs rebase on Dec 6, 2025
6. 
   Ataraxia009 commented at 4:34 am on December 7, 2025: none

   Concept NAck

   Users that are having issues that are not power users would also use the -debug option, to help submit logs. if -debug is used with this implementation, it would stop rate-limiting of all category logs.

7. 
   stickies-v commented at 10:19 am on December 7, 2025: contributor

   if -debug is used with this implementation, it would stop rate-limiting of all category logs.

   Debug logs are (by design) much higher frequency than info/warning/error level logs. They have never been ratelimited, because for debugging purposes it’s important to see what’s happening without limitation. When running with -debug, the overwhelming majority of logs produced are debug logs. This PR doesn’t change anything about any of that.

   Info logs are typically much higher signal than debug logs, that’s why they’re unconditional. Before this PR, if an info/warning/error log has a category associated with it (note: this is quite rare), and that category is activated for debugging, the user would find their higher-signal unconditional logs ratelimited, but not their debug/trace logs. That’s unintuitive, unhelpful and doesn’t really offer any additional protection, because debug logs are so much more voluminous. It also leads to more elaborate workarounds necessary such as in #34008.

   I hope that clears it up?

8. test: check that log ratelimiting also works with info+category

   This test is added just to ensure current behaviour.

   ae92cb23ae
9. log: exempt all category-specific logs from ratelimiting

   Previously, running with -debug=<category> would exempt the debug
   and trace log messages in that category from rate limiting, but
   not the info/warning/error category-specific messages (which are
   rare). This is unintuitive and unnecessary.
   
   When users run with -debug, we already assume they are power users
   and that they will have significantly higher log volumes, so there
   is no real benefit from suppressing info log messages in that
   category.
   
   Fix this by applying ratelimiting exceptions from -debug=<category>
   to all logs in that category.

   15e62e1b4f
10. net: log peer connection with NET category

    This way, when running with -debug=net, the log message (which can
    be frequent) will not get ratelimited when the user explicitly
    opts into getting higher log volumes.
    
    Introduces slight behaviour change by prefixing the log message
    with [net:info].

    9485a3c59a
11. stickies-v force-pushed on Dec 7, 2025
12. 
    stickies-v commented at 10:26 am on December 7, 2025: contributor

    Force-pushed to address merge conflict from #29641, no other changes.
13. DrahtBot removed the label Needs rebase on Dec 7, 2025
14. 
    maflcko commented at 12:19 pm on December 7, 2025: member

    LogPrintLevel isn’t really documented in the dev notes and the unit test name logging_LogPrintMacrosDeprecated seems to indicate it is deprecated. This change here seems to put a use-case to it, so it could make sense to document and test it? Though, I wonder instead of using the LogPrintLevel macro, it could make more sense to just add a new LogInfo macro that mirrors the LogDebug signature? I can’t really see a use-case to have high-volume warnings or errors, so that they run into rate-limiting. But no strong opinion, I just mentioned it, because I re-created a scripted-diff to remove LogPrintLevel for fun (probably not going to open a pull for this): af8166173f5a1d3b166e237edf259a0e5f6102bd.
15. 
    Ataraxia009 commented at 1:26 pm on December 7, 2025: none

    if -debug is used with this implementation, it would stop rate-limiting of all category logs.

    Debug logs are (by design) much higher frequency than info/warning/error level logs. They have never been ratelimited, because for debugging purposes it’s important to see what’s happening without limitation. When running with -debug, the overwhelming majority of logs produced are debug logs. This PR doesn’t change anything about any of that.

    Info logs are typically much higher signal than debug logs, that’s why they’re unconditional. Before this PR, if an info/warning/error log has a category associated with it (note: this is quite rare), and that category is activated for debugging, the user would find their higher-signal unconditional logs ratelimited, but not their debug/trace logs. That’s unintuitive, unhelpful and doesn’t really offer any additional protection, because debug logs are so much more voluminous. It also leads to more elaborate workarounds necessary such as in #34008.

    I hope that clears it up?

    Yeah the alternative option for those work arounds are not great. Having debug on should just get you less restrictions from a functionality standpoint as well.

16. 
    stickies-v commented at 11:01 pm on December 8, 2025: contributor

    Closing this in favour of #34008, I think that PR’s new approach of downgrading the inbound log to LogDebug is superior.

    I think the approach in this PR makes sense if there are other places in the code with a similar issue (modulo addressing this comment), but until that use case pops up, there’s no point keeping this PR open.

17. stickies-v closed this on Dec 8, 2025

    ---

18. 
    maflcko commented at 9:59 am on December 9, 2025: member

    I think the approach in this PR makes sense if there are other places in the code with a similar issue (modulo addressing this comment), but until that use case pops up, there’s no point keeping this PR open.

    I went ahead and implemented my comment in #34033, because it makes sense on its own, and because it makes it easier to implement the changes here in the future, if there is ever need to.

Contributors
stickies-v DrahtBot Ataraxia009 maflcko

Labels
Utils/log/libs