-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
fix(core): Normalize trace context #5171
Conversation
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.
Normalizing data looks good to me.
I am afraid that this won't resolve the actual issue as in my test app, I am already normalizing the data and still getting the same error.
That would suck. IIRC we identified the error happening in axio's non-error callback. Can you try normalizing the Edit: Discussed the issue with @vladanpaunovic in person and wrapping the |
29f0932
to
17af3a0
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.
This looks good!
packages/core/src/baseclient.ts
Outdated
// event.spans[].data may contain circular/dangerous data so we need to normalize it | ||
if (event.spans) { | ||
normalized.spans = event.spans.map(span => { | ||
// We cannot use the spread operator on span here because that overwrites the `toJSON` method |
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 because the toJSON
method is non-enumerable, and spread only copies over enumerable properties? If so, can we change the comment to say that?
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.
Yup, good point, thanks! --> 50b4b33
packages/integration-tests/suites/public-api/startTransaction/circular_data/subject.js
Show resolved
Hide resolved
|
||
expect(eventData.contexts).toMatchObject({ | ||
trace: { | ||
data: { lays: { contains: { lays: { contains: '[Circular ~]' } } } }, |
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.
Why does this go two layers deep before noticing the circularity?
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.
When I first wrote the test I didn't really care but now I looked a little bit closer and noticed that this is actually a pretty bad bug within dropUndefinedKeys
which I produced in #5163.
I adjusted tests to test for the faulty behaviour (06a2b2d) and probably fixed it (3223048). Sadly it's not very straight forward. May I ask you to take another look at the changes? Sorry about the confusion.
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.
For future readers. This was now done in #5201
} | ||
|
||
// event.spans[].data may contain circular/dangerous data so we need to normalize it | ||
if (event.spans) { |
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.
should we gate this with a tracing debug flag?
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.
I wouldn't do that. The tracing flag currently only guards code that sets up automatic instrumentation, i.e. side effect code that makes use of tracing. This allows tracing to be treeshaken if it's not in use. It can still be used, even if the flag is set to false. If we guard this here and users call startTransaction
and pass in circular data, they're not gonna have a good time. Good consideration though.
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.
Makes sense!
packages/utils/src/object.ts
Outdated
@@ -4,7 +4,6 @@ import { WrappedFunction } from '@sentry/types'; | |||
|
|||
import { htmlTreeAsString } from './browser'; | |||
import { isElement, isError, isEvent, isInstanceOf, isPlainObject, isPrimitive } from './is'; | |||
import { memoBuilder, MemoFunc } from './memo'; |
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.
maybe we can eliminate this since it's only used in 2 places? Can do in another PR
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 might be able to. Agree that when we get to it we should do this in another PR.
6710bac
to
4d6a919
Compare
It looks like this change completely clears out other sentry-javascript/packages/core/src/baseclient.ts Lines 499 to 501 in f4e3cf4
Running the Electron e2e tests after this change and all the device/os/etc contexts are stripped out. Is this intensional? |
No, and I am actually in the process of fixing it for other reasons. Stay tuned! |
Oh god. Looking at this is painful. Stupid mistake, sorry about that. Btw it appears #5218 also aims to fix this (?). |
Trace context is currently not normalized before being sent, however the
data
field in trace context is "free form" and user provided, so we need to at least normalize that. We're also fixing a bug indropUndefinedKeys
where references to the original object were kept in the "cloned"/returned object.Most likely resolves #2809
Ref: https://getsentry.atlassian.net/browse/WEB-940
This is probably not the cleanest solution. I evaluated doing the normalization a bit deeper in the stack, but ran into problems with not having the
normalizeDepth
options available and more importantly trace context data being mutated again after the normalization.