-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Allow request body to be logged if required even with successful queries #3529
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
Conversation
|
Deploy preview for hasura-docs ready! Built with commit 039cc9b |
|
Review app for commit c638941 deployed to Heroku: https://hge-ci-pull-3529.herokuapp.com |
lexi-lambda
left a comment
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 seems like it could result in pretty noisy logs, right? I don’t really have a fundamental problem with this change, but does it make sense to put this behind a flag or something? Most servers don’t log every single request payload!
This maybe useful in some cases. For example you may want to always log the request body of metadata queries. |
lexi-lambda
left a comment
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 maybe useful in some cases. For example you may want to always log the request body of metadata queries.
Ah, I see, I think I misinterpreted the diff at first glance—this doesn’t actually change the behavior at all, it just exposes the information via the HttpLog class. That seems perfectly reasonable to me, so that’s my mistake.
|
Review app for commit 039cc9b deployed to Heroku: https://hge-ci-pull-3529.herokuapp.com |
|
Review app https://hge-ci-pull-3529.herokuapp.com is deleted |
Description
LogHTTPSuccessnow has the json parsed request body (if present) as an extra argument.This is needed if we also want to log the request body with successful queries.
Affected components
Related Issues
Solution and Design
Server checklist
Catalog upgrade
Does this PR change Hasura Catalog version?
Metadata
Does this PR add a new Metadata feature?
run_sqlauto manages the new metadata through schema diffing?run_sqlauto manages the definitions of metadata on renaming?export_metadata/replace_metadatasupports the new metadata added?GraphQL
Breaking changes
No Breaking changes
There are breaking changes:
Metadata API
Existing
querytypes:argspayload which is not backward compatibleJSONschemaGraphQL API
Schema Generation:
NamedTypeSchema Resolve:-
nullvalue for any input fieldsLogging
JSONschema has changedtypenames have changedSteps to test and verify
Limitations, known bugs & workarounds