-
-
Notifications
You must be signed in to change notification settings - Fork 594
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
Improve logging of http requests to aid debugging #3485
Conversation
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.
Query parameters can contain secrets, we can't just print them all
Most of the secrets are ephemeral but some aren't single-use.
I modified to just print out the url path |
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.
Any chance of tests for this change?
I could refactor a bit and extract a sort of "HttpFetchLogger" and add some unit test, could allow to have simple unit test to see if it's handling URL as expected and doing the time correctly. Or are you thinking about more integrated tests with sending a rageshake and checking for log reports in the RS files? |
I was thinking of a basic unit test which just mocks/stubs |
It's a bit frustrating that real quality-of-life improvements like this get stuck behind a requirement for improved testing. Can we land it anyway without spending the time writing tests? |
Given it has potential to leak secrets if it is broken I'd advocate for tests to assert that it does not... |
If there are non-single-use secrets in query params, that seems like a problem, as such secrets will also get logged server-side. What are you thinking of? |
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.
Small nits
I would have personally thought the logs would make more sense with the least granular thing first e.g.
FetchHttpApi: <-- $METHOD $URL [$TIME $STATUS/$ERROR]
For scanning logs I'd have thought keeping the method & url in a fixed column position would have been helpful
Fixed the test to not have status=undefined and not use 1234 for both the port and the time
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* Log query parameters on HTTP requests Follow-up to #3485 * Only stringify once See #3591 (comment)
Since #3485, we log every request anyway, so there's no need to log twice.,
Since #3485, we log every request anyway, so there's no need to log twice.,
Checklist
Added simple logging for all requests made from the js-sdk to ease rageshakes investigation.
Fix element-hq/element-web#25570
Looks like that:udpated as per to remove url params that could contain secrets
This change is marked as an internal change (Task), so will not be included in the changelog.