-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SlogSink support to funcr #241
Conversation
8d309b3
to
7651624
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, but I've not tried to really understand all implementation details in funcr.
Yeah, I don't expect you to dig into funcr too deeply. Mostly I was interested in your take on the changes to It feels like that SHOULD be in the funcr subdir, but we also use |
As I stare at slogr_test, I am a little confused - |
I pushed another commit - please look at the "Get rid of testSlogSink" and tell me if it is wrong? |
I pushed on more commit, moving slogtests to a helper and funcr tests to funcr. |
d7be8c5
to
76cc254
Compare
One observation: because we are now testing only with a To restore full coverage, we would have to define a |
What would you say to having an internal trivial implementation which is basically discard but not nil? We could have one which supports SlogSink and one which does not. I guess that is testLogSink... |
Are we generating a coverage report for PRs? |
For
No. I was testing locally because I wanted to understand whether moving the testing around had an effect. There's an effect of the PR, it's just because for another reason. |
|
||
// | ||
// slogSink wrapper of discard | ||
// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you learn anything from these benchmarks? I'm just curious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I learned that funcr with JSON is more than 2x faster than slog's JSON handler, but has more allocs. And that the slogSink (wrapper) path is (as expected) low overhead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a similar comparison between slog's JSON handler and zap (kubernetes/kubernetes@9100c3c). Slog was slower, so there was no justification for switching from zap to slog as backend in Kubernetes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I have your attention (sorry, couldn't resist 😁 ), could you perhaps review the PR in Kubernetes that this commit came from? The dependency update is in another pending PR, that's the only reason it's WIP.
I am cooking something wrt test impls and coverage. |
I have an extra commit in flight, but opinion wanted. I can make |
OK, I added a big commit. It makes sloghandler pass almost all of the slog tests wrt I could abandon the maps part and just go back to dot-prefixes (simpler, won't pass as many slog tests but maybe OK?). Opinion wanted. |
I prefer to keep |
After having done it, I think I agree. Though the testing is satisfying :) |
One last thought: as it is, with prefixes, someone who calls:
gets a different result than:
It's |
Is that perhaps because I can see how this happens with a simple test sink based on funcr. I think "real" sinks will fully support slog, then the |
c6e67c9
to
0dd6551
Compare
I pushed now with a much simpler change to sloghandler, coverage is restored, tests are cleaner (IMO). PTAL. |
uses: actions/setup-go@v4 | ||
with: | ||
go-version: '>=1.21.0' | ||
cache: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we should cover the new code with linting. I don't think it's worth to lint also with older Go because the non-slog code isn't that complex and going away at some point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i cant tell if you are agreeing with me or want a change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you.
if attr.Key != "" { | ||
kvList = append(kvList, l.addGroupPrefix(attr.Key), attr.Value.Resolve().Any()) | ||
} | ||
kvList = attrToKVs(attr, l.groupPrefix, kvList) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this code change deserves to be a separate commit with a description of why it is made. Right now it is in "Clean up slog testing and restore coverage" which doesn't tell me why sloghandler.go needs to be changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can either a) break this last commit to a PR which applies AFTER this PR (rebasing it is tedious and it has a lot of deps on other commits); or b) beef up the comments.
I'll do B now and you can decide if you prefer A.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pushed
pushed with small changes, will look at splitting sloghandler to a new PR or beefing up comments. |
// and other details of slog. | ||
func attrToKVs(attr slog.Attr, groupPrefix string, kvList []any) []any { | ||
attrVal := attr.Value.Resolve() | ||
if attrVal.Kind() == slog.KindGroup { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this is the "retools sloghandler to handle slog Attrs a bit better" part.
Looks okay to me now. Let's rebase and then merge it without further refactoring (your plan B).
Some of the testing done in slogr_test.go should probably be in funcr, but the test jig is just complex enough that I don't want to duplicate it in this commit. Later.
This uncovered a bug where it would sometimes write to the input list, corrupting tests.
rebased and pushed |
See commits for comments. This unearthed at least 3 bugs.
funcr now passes all but one of the slog tests (that being the timestamp one).