-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
feat: unpack payload into log function #28521
Conversation
Pass down the payload dict (merged from the ? querystring and POST data, depending on context) and pass it to the log function. In my specific case, I was looking to do analysis on around how much of the calls to `ChartDataRestApi.data` are using "force=true", and realize while this is in context, it doesn't flow through my current logger. By adding this one line of code, it should allow for many more (in fact ALL querystring and POST payload) parameters to flow through the logger. From there custom loggers can have access to much more context. Note that by default, the loggers we have won't do anything with the new arguments passed, and essentially flush it.
POST payload can have sensitive data |
Totally - though that variable is just passed to the logger, not logged. Actually let me improve this a bit. I'll pass more explicitely a |
@dpgaspar I took a different approach, let me know what you think |
"database_id": None, | ||
"user_id": 2, | ||
"duration": 5558756000, | ||
"curated_payload": {}, |
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.
would be nice to actually have tests with the curated payload
Unpack the payload (merged from the ? querystring and POST data, depending on context) and pass it to the log function. In my specific case, I was looking to do analysis on around how much of the calls to
ChartDataRestApi.data
are using "force=true", and realize while this is in context, it doesn't flow through my current logger. By adding this one line of code, it should allow for many more (in fact ALL querystring and POST payload) parameters to flow through the logger. From there custom loggers can have access to much more context. Note that by default, the loggers we have won't do anything with the new arguments passed, and essentially flush it.