-
-
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
feat(core): Deprecate Span.op
in favor of op attribute
#10189
Conversation
data: { | ||
'sentry.op': 'test op', | ||
}, |
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 noticed that spanToJson
sets the op also in data
because it's saved as an attribute. Should we change this in the spanToJson
implementation? I'd imagine, this would just be duplicated data in the product as we still need the top level event.op
field anyway.
thoughts @mydea @AbhiPrasad?
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 would leave it in, I think - rather if we don't want to send this, we can/should remove it wherever we generate the event 🤔 eventually (after v8? let's see..) I think any special handling of op
& origin
should go away and they should only be kept as attributes everywhere. But for now we can just keep both I believe...?
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.
eventually (after v8? let's see..) I think any special handling of op & origin should go away and they should only be kept as attributes everywhere
Agreed, that makes sense to me, thanks! Ok, I'll leave it in then and adjust the tests to accomodate the new behaviour. Worth pointing out that this isn't breaking anything, it's just adding a new data item anyhow.
size-limit report 📦
|
840c720
to
d65726c
Compare
@@ -1,5 +1,6 @@ | |||
/// <reference types="next" /> | |||
/// <reference types="next/image-types/global" /> | |||
/// <reference types="next/navigation-types/compat/navigation" /> |
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 on purpose here? Just to clarify!
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.
huh no, no idea how this happened, thx for catching!
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.
Ah maybe because I ran the NextJS integration tests locally.
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.
very nice!
cd9f4a8
to
29c0ce5
Compare
9606c1d
to
bfdd5a6
Compare
fix missing eslint ignore after rebase :( migration doc revert next-env.d.ts change once again fix things after rebasing :(
bfdd5a6
to
7b687f6
Compare
This PR deprecates
Span.op
in favour of:spanToJson
to get the span opstartSpan
functions to set the initial span opsetAttribute('SEMANTIC_ATTRIBUTE_SENTRY_OP', ...)
to update the span opGoing forward, the span op will become a semantic, Sentry-specific span attribute. With this PR we already set, get and update the attribute but still provide the deprecated
op
getter and setter for v7 backwards compatibility.Added behaviour:
spanToJson
currently writes attributes intospan.data
, meaningsentry.op
becomes a new field on thedata
object in addition to being set on the top levelop
property. After discussing this, it's probably okay to have this duplication at the moment. In an only-spans future, we'll likely remove the top levelop
property all together so we should be good.The side effect is that I imagine a new
sentry.op
field could be visible in the product UI when looking at span/transaction data.ref #10184