-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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(browser): Allow to capture request payload/responses #7287
Conversation
status_code, | ||
}; | ||
|
||
if (options.captureRequestPayload && body) { |
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.
We should probably capture falsy body
values, no?
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.
Good question, wasn't so sure about that. the response body seemed to be ''
when "empty", the request body undefined
. We can also just pass this through as-is and just not care what it is! WDYT?
data: { | ||
...handlerData.fetchData, | ||
status_code: handlerData.response.status, | ||
if (options.captureRequestPayload && handlerData.args[1] && handlerData.args[1].body) { |
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.
Same question here irt falsy body
if (text) { | ||
handlerData.fetchData.response_payload = text; |
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.
And here for falsy values
Replay SDK metrics 🚀
develop |
Revision | LCP | CLS | CPU | JS heap avg | JS heap max | netTx | netRx | netCount | netTime |
---|---|---|---|---|---|---|---|---|---|
4b95c04 | +57.56 ms | -0.00 ms | +7.94 pp | +920.88 kB | +1.05 MB | +2.21 kB | +41 B | +1 | +90.32 ms |
e60cd02 | +56.25 ms | -0.00 ms | +6.32 pp | +927.44 kB | +1.06 MB | +2.21 kB | +41 B | +1 | +117.55 ms |
e25c067 | +48.34 ms | +0.00 ms | +5.59 pp | +926.37 kB | +1.05 MB | +2.22 kB | +41 B | +1 | +65.23 ms |
b1b249b | +43.88 ms | +0.00 ms | +4.80 pp | +937.99 kB | +1.05 MB | +2.22 kB | +41 B | +1 | +111.56 ms |
12e34d4 | +28.57 ms | +0.00 ms | +5.77 pp | +930.12 kB | +1.04 MB | +2.26 kB | +41 B | +1 | +109.67 ms |
c46c56c | +65.45 ms | -0.00 ms | +5.38 pp | +930.26 kB | +1.07 MB | +2.21 kB | +41 B | +1 | +91.29 ms |
7f4c4ec | +56.64 ms | -0.00 ms | +5.57 pp | +927.42 kB | +1.06 MB | +2.21 kB | +41 B | +1 | +110.83 ms |
00d2360 | +55.18 ms | +0.00 ms | +2.23 pp | +934.14 kB | +1.05 MB | +2.22 kB | +41 B | +1 | +71.65 ms |
Last updated: Tue, 28 Feb 2023 00:27:39 GMT
size-limit report 📦
|
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.
As long as we strictly keep this opt-in, this LGTM.
Are we closing this one? |
I will, working on a replacement for the sizes only at the moment, will close this once this is up (hopefully today)! |
Closed in favor of #7589 |
This adds a new opt-in config for the
Breadcrumbs
integrations to also capture request payload/responses:If these are set, we add
request_payload
and/orresponse_payload
fields to the xhr/fetch breadcrumbs. An example breadcrumb would then be:For replays, we also pass these through as
requestPayload
/responsePayload
(note that we seem to be using camelCase in replay breadcrumbs, snake_case in the general breadcrumbs).Some notes on this/things to consider:
await response.text()
). However as long as this is not enabled it shouldn't actually change the timing.Closes #7103