-
Notifications
You must be signed in to change notification settings - Fork 88
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
[Feature Request][Bug?] Request-scope LoggingUtils setting of keys #452
Comments
I've had a look at both Java and Python versions documentation
The python version's documentation is clear about the expected behaviour but also provides a way to achieve the behaviour I described as desired https://awslabs.github.io/aws-lambda-powertools-python/latest/core/logger/#clearing-all-state |
Thanks for opening the issue and findings. I will bring in feature parity with python version 👍🏼 |
This is great! Thanks a lot for the quick action @pankajagrawal16 A small question, this should work even if |
Yes it will work either way, since we are clearing the MDC context of log4j |
Is your feature request related to a problem? Please describe.
My team uses Powertools core utilities (Logging, Metrics and Tracing) in one of our Lambda functions.
In that, we rely on
LoggingUtils.appendKeys
andmetricsLogger().putProperty
to append specific request-related key/value pairs that improve our ability to debug issues and run adhoc queries using CloudWatch Logs Insights.We've discovered an issue with our logging that values set via
LoggingUtils.appendKeys
are not cleared after the request is done, they instead get carried over to the following requests unless those key/value pairs are overridden which led to wrong key/value pairs being associated with a given request's log lines.This is an unexpected behaviour, our assumption was that logging properties set in a given request, would just be scoped to that request.
Describe the solution you'd like
Setting logging properties via
LoggingUtils.appendKeys
should be scoped to a request i.e. they should be automatically cleared after the request is completed.The behaviour where properties are carried over from one request to the next, opens a door for logging bugs as in Lambda.
Describe alternatives you've considered
The main alternative, and current mitigation, is to explicitly clear the logging properties using
LoggingUtils.removeKeys
. While it achieves the same result, it's cumbersome - as it requires tracking the keys to clear.The text was updated successfully, but these errors were encountered: