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(replay): Add experiment to capture request/response bodies #7589
Conversation
packages/replay/src/types.ts
Outdated
|
||
request?: { | ||
size?: number; | ||
body?: string; |
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.
Q @billyvg & @ryan953: Is it OK to just always pass this as string, or should we pass a POJO if it is JSON?
String pro:
- It is easier
- It is less error prone
- Less bytes on the client
POJO pro:
- Easier to differentiate what is JSON vs. what is a string (for UI)
- I guess PII stripping would work differently, and not redact the whole body but only certain fields?
Maybe we can also do the string->POJO conversion server side, to get both benefits in one package...? cc @cmanallen as well
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.
Whatever makes network load better is my preference. Since we only show one response at a time parsing & client memory should be fine.
As a stringy value we can do try { JSON.parse() }
and hope for the best.
Headers could guide this too, but any 3rd-party or custom mime type would annoying to deal with, so we'd probably just ignore headers for this transform anyway.
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.
sounds good!
We'll add headers in a follow up PR, we can still look into using them if we want to/need to.
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.
@mydea Let's go with POJO - I think redacting the whole body is a worse experience than individual fields.
size-limit report 📦
|
dbef016
to
2cbc520
Compare
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.
Is this redundant with captureBodies
test?
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 tests that without the experiment we do not capture the body!
packages/replay/src/types.ts
Outdated
|
||
request?: { | ||
size?: number; | ||
body?: string; |
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.
@mydea Let's go with POJO - I think redacting the whole body is a worse experience than individual fields.
2cbc520
to
218c30c
Compare
I updated this:
|
053b301
to
0a81c64
Compare
Update:
response: {
size: 400_000,
_meta: {
errors: ['MAX_BODY_SIZE_EXCEEDED']
}
} |
0a81c64
to
1b83e65
Compare
New 'Network details' panel. Figma per [figma](https://www.figma.com/file/SVyNvm8p17xGfIC7r7l2YS/Specs%3A-Network-Request-Details?node-id=4%3A7443&t=VjNMXfMJQKHfj0ks-0) specs There are a few states so observe in the screen shots, and some followup tasks Note that: - You can only open the details panel for xhr & fetch network types - The data is a string that's run through the pii scrubber, we try to parse it with `JSON.parse`, but if that fails you'll just get a string | State | Img | | --- | --- | | Click a network row to open the Details. Notice that the row you clicked is Bold. The lower area with the data is scrollable, strings or objects will display | ![SCR-20230323-km4](https://user-images.githubusercontent.com/187460/227372507-b093de12-66df-4383-a46f-650a488c7821.png) | | The X button will close the panel | ![SCR-20230323-kmb](https://user-images.githubusercontent.com/187460/227372508-18954b0a-c593-4aa8-9eca-49a99f191685.png) | | Click+drag (don't click on the tabs or the X button) to make the panel larger/smaller | ![SCR-20230323-kmd](https://user-images.githubusercontent.com/187460/227372509-a3318199-01ef-486d-a00b-ece5008ca465.png) | Related to getsentry/sentry-javascript#7589 Fixes #46054
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.
Tested this with the new UI and it's working great!
We moved the size field in the sdk in getsentry/sentry-javascript#7589 Note that this field is for XHR/fetch and reflects the decoded body size whereas the other `data.size` fields are *transfer* size (i.e. over the network). We may want to consider changing to show decoded body size for all, though that was only recently added to the SDK.
1b83e65
to
496fdbc
Compare
We moved the size field in the sdk in getsentry/sentry-javascript#7589 Note that this field is for XHR/fetch and reflects the decoded body size whereas the other `data.size` fields are *transfer* size (i.e. over the network). We may want to consider changing to show decoded body size for all, though that was only recently added to the SDK.
This adds a new experiment:
captureNetworkBodies
that, when enabled, will attach the request/response body to the replay breadcrumb.In the process of doing this I moved the network breadcrumb stuff around a bit, IMHO it is a bit clearer now how things work together.
The responding breadcrumbs will look like this:
Note that the
response.size
andrequest.size
will be sent anyhow, even without the experiment.This removes the (shortly available)
requestBodySize
andresponseBodySize
fields.ref #7103