chore: use error message as value on slog adapter #374
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lukasmalkmus
approved these changes
Aug 19, 2025
There was a problem hiding this comment.
Hi!
Sorry for being late to the party.
I believe this is an absolutely legitimate fix.
Personally, I usually have an slogx package with my projects and one of the exported functions is as simple as:
func Err(err error) slog.Attr {
return slog.Any("error", err.Error())
}But given this is a common pitfall and the stdlib implementation handles it explicitly, as well, I can totally accept this fix.
Cheers and thanks for your contribution!
92785e5 to
060fd18
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds special handling for error values in the slog adapter to ensure their error messages are used.
Previously, when sending an error as an Any value, it would be converted into an empty map[string]interface{}. This caused the value to be ignored by Axiom.
To address this, I added a special case to handle values that are instances of error, similar to how the std JSONHandler handles them.
i get that this somewhat breaks the flow of the code and the user can easily resolve this by explicitly writing:
instead of
But in my option this gets annoying to do pretty quick
There is an argument to be made that the entire
addAttrToEventfunction should be rewritten IF the intention is to replicate the behavior of the std JSONHandler.Witch in my understanding kinda is because a JSON in what axiom is getting,but i can be wrong and that's ok
That said, this PR focuses on addressing the specific issue of handling error values, and a broader rewrite could be considered as a separate improvement.