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.
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
fix(metadata precedence) - fix metadata override issues #1989
fix(metadata precedence) - fix metadata override issues #1989
Changes from all commits
e2d4402
29a9ff7
23d9036
5df5786
4b0624b
d23801d
c942452
e72d96b
4495caa
f951b9a
6ba9967
fd14dfe
70fa754
e18e1bb
692de0d
dc005b7
f2ee50a
85ea8a6
b233a8b
ce2f607
96dfeda
b44d4b1
f748636
f350f2c
f89285a
b2efe8f
010e955
f393a50
3577d1d
fc39513
d9f105c
8eab107
4c544f1
4e830d6
8724f4b
a2ec0c2
c4dd5ea
b36158f
830d15b
97a87b6
ddb4dd1
0198284
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 forget most of the design decisions here. Should this be called
defaultMeta
, or ismeta
more appropriate? I don't recall, maybe I will remember more or learn more as I read through 😬 Some docs around recommended usage for meta stuff would be useful (if we don't already have that), although I see a bunch of tests down below so maybe those are pretty self-documenting :)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.
So this is a great question. The short answer is that it's consistent with every other usage regarding configuring default metadata.
I want to preface the following with it's possible that I'm way off base in my understanding of how
defaultMeta
is supported overall. As far as I can tell there is no explicit definition of adefaultMeta
property on our Logger instance anywhere. Although we reference it in so many places. As such I believe that this is a "convention" based implementation and not necessarily a 1st class implementation. If my presumptions here are accurate, it's extremely important that this convention is not broken.P.S. It is possible that there's a configuration that I'm unaware of that's leveraged in the dynamic
Object.defineProperty
calls that would make this non convention based; but I haven't seen anything as of yet.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.
What is this for? This looks unrelated to child loggers / metadata -- is this fixing some other issue, or is it indeed related? If it's related, a comment might be helpful explaining why?
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 believe this to have been an issue with the SPLAT implementation and associated hotpath optimizations. If I am remembering correctly this stemmed from this comment on my previous PR. Additional discussion was had in #1596 way back when. If we want to remove this addition from this addition I'm happy to (so long as all my tests that I've written are still passing. 😃
Edit: I've verified all my tests work without this implementation. Happy to remove. Alternatively I can try and find some time to add in some additional SPLAT tests to re-verify my understanding of this addition; although that may take some time. About to be fairly busy in the coming weeks.
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.
Wait, so
Object.assign(msg, this.defaultMeta);
doesn't mutatemsg
? ButObject.assign(msg, this.defaultMeta, msgClone);
does? This comment confused me a bit... and then I'm also confused whymsg
is getting merged withmsgClone
. Is it just to ensuremsgClone
's metadata is used instead ofdefaultMeta
? But then wouldn't there be some simpler way to write that rather than usingObject.assign
?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.
So this is a mutating operation. The issue with this mutation is that we lost the ability to apply the metadata defined in the appropriate order of precedence.
Considerations:
msg
itself as it's what is used in thewrite
method; therefore it must be the target of this operationmsg
's configured metadataDue to the above, and the fact that we HAVE to mutate
msg
given the current dependency of other code paths (such aswrite
), we have to have a means to reapply anymsg
specific metadata that overrides default metadata. Without this the default metadata will always take precedence.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.
Super late to the party, but because of this change there is no possibility of logging instances of error objects in any way. All the previous suggestions of adding custom formatters in order to extract separate parts of the error object are not applicable anymore. By the time any formatter is called, the error object was already stringified and parsed back, thus losing message, stack, etc. props. As of now, a user of this library should choose: be able to log errors or use defaultMeta logger property.
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.
This looks to be the case. I was under the impression at the time that the ErrorFormatter addressed the use case sufficiently. Obviously I was wrong in that respect. Hence why we did a patch release to "revert" the regression.
I'm going to be working through these scenarios this week ideally to fix the regression contained within the metadata fixes. Any test cases you have would be hugely appreciated!!
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.
Are there any side-effects if I follow this approach?
const msgClone = JSON.parse(jsonStringify(msg)); Object.assign(msg, this.defaultMeta, msgClone);
cause I am facing the issue where defaultMeta is overriding my msg data.