Unable to change level during execution via LevelVar
Slog handlers can use LevelVar to specify the handler logging level.
Unlike specifying a Level (which is actually an int),
a LevelVar is supposed to be changeable during program execution.
Handlers
Tests
Svcrunner Jsonlog
Level Var
Mismatch
Logged record does not match expected
During benchmark testing the test is run once to see if the logged record matches expectations.
NotDisabled
Logging was not properly disabled
During benchmark testing a Debug log line is made with the current level set to Info.
This warning is thrown if there is any logged output.
Resolve Group Resolve Group With Resolve Valuer Resolve With
SlogTest
Failure of embedded slog/slogtest
Documentation on building a handler suggests testing using slog/slogtest, part of the Go release since 1.21.
While the verification suite includes tests patterned after those in slogtest,
an additional single test invokes the slogtest testing sequence (involving multiple tests).
Since this is a separate package, all error messages are returned at once.
This is the only warning that affects TestSlogTest and all of its error messages.
The slog.Record.PC field can be loaded with a program counter (PC).
This is normally done by the slog.Logger code.
If the PC is non-zero and the slog.HandlerOptions.AddSource flag is set
the source field will contain a slog.Source record
containing the function name, file name, and file line at which the log record was generated.
If the PC is zero then this field and its associated group should not be logged.
should have attrs2 within the group group1 (along with attrs1).
The current handler places attrs2 at the top level.
The preceding example applies to all of the "message" methods (e.g. Error(), Debug()).
This sequence is verify specific, neither attrs1 and attrs2 can be empty or missing.
LevelMath
Log levels are not properly treated as integers
Log levels are actually numbers, with space between them for user-defined levels.
Handlers should properly handle numeric levels and math applied to level values.
Handlers
Tests
Chanchal Zap
Default Level Level Configured Level Different Level Var
MessageKey
Wrong message key (should be 'msg')
The field name of the "message" key should be msg.
Canceled Context Keys Source Key Zero PC Zero Time
NoReplAttr
HandlerOptions.ReplaceAttr not available
If HandlerOptions.ReplaceAttr
is provided it should be honored by the handler.
However, documentation on implementing handler methods seems to suggest it is optional.
Replace Attr Replace Attr Basic Replace Attr Fn Change Key Replace Attr Fn Level Case Replace Attr Fn Multi Replace Attr Fn Remove Empty Key Replace Attr Fn Remove Time
NoReplAttrBasic
HandlerOptions.ReplaceAttr not available for basic fields
Some handlers (e.g. phsym/zeroslog) support
HandlerOptions.ReplaceAttr
except for the four main fields time, level, msg, and source.
When that is the case it is better to use this (WarnNoReplAttrBasic) warning.
Replace Attr Basic Replace Attr Fn Change Key Replace Attr Fn Level Case Replace Attr Fn Multi Replace Attr Fn Remove Empty Key Replace Attr Fn Remove Time
ReplAttrGroup
ReplaceAttr groups argument usage results in an error
A ReplaceAttribute function has two arguments: an array of strings representing group names and an attribute.
The TestReplaceAttrGroup test checks to see if group names are properly passed.
This test may fail due to unrelated causes that show up as warnings for other tests.
SourceCaller
Source data logged as 'caller' instead of 'source'
Some handlers return source data as a single string on the caller field
in the format <file>:<line> where <file> and <line> correspond
to the File and Line fields of the source data group and Function is not provided.
WithGroup doesn't embed following attributes into group
Complex log statements involving WithGroup require attributes to be attached to groups.
This warning represents situations where the attributes are attached to the wrong log group.
Handlers
Tests
Chanchal Zap
Group With Multi Group With Multi Sub Empty
Suggested
Warnings not mandated by any documentation or requirements. May be suggested due to the behavior of slog/JSONHandler.
Duplicates
Duplicate field(s) found
Some handlers (e.g. slog.JSONHandler)
will output multiple occurrences of the same field name
if the logger is called with multiple instances of the same field,
generally by using WithAttrs and then the same fields in the eventual log call (e.g. Info).
This behavior is currently under debate
with no resolution at this time (2024-01-15) and a
release milestone of (currently unscheduled) Go 1.23,
(whereas Go Release 1.22
is currently expected in February 2024).
Handlers
Tests
Chanchal Zap Madkins Flash Madkins Repl Attr Madkins Sloggy Phsym Zerolog Phuslu Slog Slog JSON Svcrunner Jsonlog
Attribute Duplicate Attribute With Duplicate
DurationMillis
slog.Duration() logs milliseconds instead of nanoseconds
The slog.JSONHandler uses nanoseconds for time.Duration but some other handlers use seconds.
slog.Duration() logs a string representation instead of nanoseconds
The slog.JSONHandler uses nanoseconds for time.Duration but some other handlers use a string representation.
Handlers
Tests
Svcrunner Jsonlog
Group Duration Log Attributes
GroupDuration
Some handlers that change the way time.Duration objects are logged (see warnings DurationMillis and DurationSeconds)
only manage to make the change at the top level of the logged record, duration objects in groups are still in nanoseconds.
Handlers
Tests
Samber Zap Samber Zerolog
Group Duration
GroupWithTop
^WithGroup().With()^ ends up at top level of log record instead of in the group
Almost all handlers treat logger.WithGroup(<name>).With(<attrs>) as writing <attrs> to the group <name>.
Some handlers write <attrs> to the top level of the log record.
Handlers
Tests
Chanchal Zap
Group With Top
LevelCase
Log level in lowercase
Each JSON log record contains the logging level of the log statement as a string.
Different handlers provide that string in uppercase or lowercase.
Documentation for slog.Level
says that its String() and MarshalJSON() methods will return uppercase
but UnmarshalJSON() will parse in a case-insensitive manner.
Canceled Context Key Case Keys Source Key Zero PC Zero Time
LevelWrong
Log level is incorrect
The log level name is not what was expected (e.g. "WARNING" instead of "WARN").
This is different from the LevelCase warning which is from the right level name but the wrong character case.
Handlers
Tests
Samber Logrus
Key Case
NoEmptyName
Attributes with empty names are not logged
Until documented otherwise, an attribute with an empty field name ("") and a non-nil value should be logged.
map[string]any converted to strings in log records
The slog.JSONHandler converts Any objects that are map[string]any into JSON maps.
Some handlers convert these Any objects into strings instead of maps.
TimeMillis
slog.Time() logs milliseconds instead of nanoseconds
The slog.JSONHandler uses nanoseconds for time.Time but some other handlers use milliseconds.
This does not apply to the basic time field, only attribute fields.
I can't find any supporting documentation or bug on this but
Go issue 59345 (see previous warning)
may have fixed this as well in Go 1.21.
The slog.JSONHandler uses nanoseconds for time.Time but some other handlers use seconds.
This does not apply to the basic time field, only attribute fields.
I can't find any supporting documentation or bug on this but
Go issue 59345 (see previous warning)
may have fixed this as well in Go 1.21.
Administrative
Warnings that provide information about the tests or conflicts with other warnings.
NoHandlerCreation
Test depends on unavailable handler creation
Some benchmark tests depend on access to a slog.Handler object.
Some slog implementations create a slog.Logger but no slog.Handler.
In this case the relevant benchmark tests can't be run.
SkipDedup
Test depends on dedup order
Some dedup tests return results that can't easily be tested.
Attribute Duplicate Attribute With Duplicate Complex Cases
TestError
Test harness error
Some sort of error has occurred during testing.
This will generally require a programming fix.
Undefined
Undefined Warnings(s)
An attempt to call WarnOnly with an undefined warning.
Warnings must be predefined to the Manager prior to use.
Unused
Unused Warnings(s)
If a warning is specified but the condition is not actually present
one of these warnings will be issued with the specified warning.
These are intended to help clean out unnecessary WarnOnly settings
from a test suite as issues are fixed in the tested handler.
