So, if the configured log level is fatal, only fatal messages should be emitted.
Goal
Change the log level filtering logic so that the configured level acts as a minimum severity threshold.
Acceptance criteria
debug logs all levels.
info logs info, warn, error, and fatal.
warn logs warn, error, and fatal.
error logs error and fatal.
fatal logs only fatal.
Tests are added or updated to cover all configured levels.
Documentation/config comments are updated to explain the threshold semantics.
<p>Currently, log level filtering works in an inverted way.</p><p>We have the following log levels:</p><pre><code class="language-text">debug < info < warn < error < fatal
</code></pre><p>At the moment, when the configured log level is set to <code>fatal</code>, the logger emits lower-severity messages as well, such as <code>info</code>, <code>warn</code>, and <code>error</code>.</p><p>Example of current behavior:</p>
Configured level | Currently logged levels
-- | --
fatal | info, warn, error, fatal
<p>So, if the configured log level is <code>fatal</code>, only <code>fatal</code> messages should be emitted.</p><p><strong>Goal</strong></p><p>Change the log level filtering logic so that the configured level acts as a minimum severity threshold.</p><p><strong>Acceptance criteria</strong></p><ul><li><p><code>debug</code> logs all levels.</p></li><li><p><code>info</code> logs <code>info</code>, <code>warn</code>, <code>error</code>, and <code>fatal</code>.</p></li><li><p><code>warn</code> logs <code>warn</code>, <code>error</code>, and <code>fatal</code>.</p></li><li><p><code>error</code> logs <code>error</code> and <code>fatal</code>.</p></li><li><p><code>fatal</code> logs only <code>fatal</code>.</p></li><li><p>Tests are added or updated to cover all configured levels.</p></li><li><p>Documentation/config comments are updated to explain the threshold semantics.</p></li></ul>
Proposal: add threshold-style level filtering without breaking current API
Current SetLevel semantics are non-standard: FATAL still allows INFO, WARN, and ERROR, while only DEBUG is filtered out. This works, but it is surprising for users who expect threshold-style logging.
Proposal
Add a new threshold-based API alongside the current one, without changing existing behavior in v2.
Possible shape:
SetThreshold(level LogLevel) *Logger
optional internal field separate from current level
log emission checks threshold semantics when threshold is configured
Expected threshold behavior:
DEBUG => allow everything
INFO => allow INFO, WARN, ERROR, FATAL
WARN => allow WARN, ERROR, FATAL
ERROR => allow ERROR, FATAL
FATAL => allow only FATAL
Goals
preserve backward compatibility in v2
provide a more familiar filtering model
make future migration to v3 easier if threshold becomes the default
## Proposal: add threshold-style level filtering without breaking current API
Current `SetLevel` semantics are non-standard: `FATAL` still allows `INFO`, `WARN`, and `ERROR`, while only `DEBUG` is filtered out. This works, but it is surprising for users who expect threshold-style logging.
### Proposal
Add a new threshold-based API alongside the current one, without changing existing behavior in `v2`.
Possible shape:
- `SetThreshold(level LogLevel) *Logger`
- optional internal field separate from current `level`
- log emission checks threshold semantics when threshold is configured
Expected threshold behavior:
- `DEBUG` => allow everything
- `INFO` => allow `INFO`, `WARN`, `ERROR`, `FATAL`
- `WARN` => allow `WARN`, `ERROR`, `FATAL`
- `ERROR` => allow `ERROR`, `FATAL`
- `FATAL` => allow only `FATAL`
### Goals
- preserve backward compatibility in `v2`
- provide a more familiar filtering model
- make future migration to `v3` easier if threshold becomes the default
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Currently, log level filtering works in an inverted way.
We have the following log levels:
At the moment, when the configured log level is set to
fatal, the logger emits lower-severity messages as well, such asinfo,warn, anderror.Example of current behavior:
Configured level | Currently logged levels -- | -- fatal | info, warn, error, fatalSo, if the configured log level is
fatal, onlyfatalmessages should be emitted.Goal
Change the log level filtering logic so that the configured level acts as a minimum severity threshold.
Acceptance criteria
debuglogs all levels.infologsinfo,warn,error, andfatal.warnlogswarn,error, andfatal.errorlogserrorandfatal.fatallogs onlyfatal.Tests are added or updated to cover all configured levels.
Documentation/config comments are updated to explain the threshold semantics.
Proposal: add threshold-style level filtering without breaking current API
Current
SetLevelsemantics are non-standard:FATALstill allowsINFO,WARN, andERROR, while onlyDEBUGis filtered out. This works, but it is surprising for users who expect threshold-style logging.Proposal
Add a new threshold-based API alongside the current one, without changing existing behavior in
v2.Possible shape:
SetThreshold(level LogLevel) *LoggerlevelExpected threshold behavior:
DEBUG=> allow everythingINFO=> allowINFO,WARN,ERROR,FATALWARN=> allowWARN,ERROR,FATALERROR=> allowERROR,FATALFATAL=> allow onlyFATALGoals
v2v3easier if threshold becomes the defaultOr
SetThresholdMode(), which will "flip" level