feat(replay): Add event to capture options on checkouts #8011
Conversation
|
@mydea Thoughts on this approach? Not sure if it's better here or when we flush |
| networkRequestHeaders: options.networkRequestHeaders.length > 0, | ||
| networkResponseHeaders: options.networkResponseHeaders.length > 0, |
There was a problem hiding this comment.
| networkRequestHeaders: options.networkRequestHeaders.length > 0, | |
| networkResponseHeaders: options.networkResponseHeaders.length > 0, | |
| networkRequestHasHeaders: options.networkRequestHeaders.length > 0, | |
| networkResponseHasHeaders: options.networkResponseHeaders.length > 0, |
? for symmetry, maybe?
There was a problem hiding this comment.
I was looking at the config but maybe this changed...
It looks like req & resp either both have headers, bo both do not. But these two fields networkRequestHasHeaders and networkResponseHasHeaders makes it seem like there could be an XOR kind of case, where one has headers and the other doesn't?
There was a problem hiding this comment.
@ryan953 yeah it's possible we have an XOR case
There was a problem hiding this comment.
these fields tell us if users have configured additional headers for request/response.
|
Tests still need some work, it's going to be a bit annoying because it's testing against the stringified payload and ordering needs to be exact :( |
size-limit report 📦
|
Add a custom event that captures configuration options on checkout + segment 0.
billyvg
force-pushed
the
feat-replay-capture-sdk-settings-in-event
branch
from
7020963 to
16e575a
Compare
Add a custom event that captures configuration options on checkout + segment 0.
Closes #7140
Closes #8004