feat(core): Add updateSpanName helper function
#14291
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
size-limit report 📦
|
Lms24
force-pushed
the
lms/feat-span-updatename-wrapper
branch
from
70674de to
c7b6718
Compare
|
❌ We are unable to process any of the uploaded JUnit XML files. Please ensure your files are in the right format. |
6 tasks
Lms24
commented
Nov 14, 2024
| }, | ||
| ], | ||
| [ | ||
| 'works with prefetch request', |
Member
Author
There was a problem hiding this comment.
This is just an additional test I added because we didn't test the condition to add .prefetch to the op.
mydea
reviewed
Nov 15, 2024
...tegration-tests/suites/tracing/browserTracingIntegration/pageload-update-txn-name/subject.js
Outdated
Show resolved
Hide resolved
mydea
reviewed
Nov 15, 2024
mydea
reviewed
Nov 15, 2024
...-integration-tests/suites/tracing/browserTracingIntegration/pageload-update-txn-name/test.ts
Show resolved
Hide resolved
mydea
reviewed
Nov 15, 2024
mydea
reviewed
Nov 15, 2024
| const httpMethod = attributes[ATTR_HTTP_REQUEST_METHOD] || attributes[SEMATTRS_HTTP_METHOD]; | ||
| if (httpMethod) { | ||
| return descriptionForHttpMethod({ attributes, name, kind }, httpMethod); | ||
| return descriptionForHttpMethod({ attributes, name: getOriginalName(spanName, attributes), kind }, httpMethod); |
Member
There was a problem hiding this comment.
m: Instead of repeating getOriginalName, can we just do this at the very top of this method and then use this processed name everywhere below?
Member
Author
There was a problem hiding this comment.
I wanted to do this initially but then we'd potentially lose the inferred op, no?
mydea
reviewed
Nov 15, 2024
mydea
reviewed
Nov 15, 2024
3 tasks
Lms24
force-pushed
the
lms/feat-span-updatename-wrapper
branch
from
32d395d to
5b42422
Compare
Lms24
force-pushed
the
lms/feat-span-updatename-wrapper
branch
from
5b42422 to
1c71162
Compare
mydea
reviewed
Dec 13, 2024
mydea
reviewed
Dec 13, 2024
Lms24
force-pushed
the
lms/feat-span-updatename-wrapper
branch
from
adee375 to
24e8320
Compare
mydea
reviewed
Dec 13, 2024
mydea
reviewed
Dec 13, 2024
mydea
reviewed
Dec 13, 2024
mydea
approved these changes
Dec 16, 2024
Lms24
added a commit
that referenced
this pull request
Dec 16, 2024
Add `Sentry.updateSpanName()` to reliably update span names in OpenTelemetry environments; prevents overwrites from both OpenTelemetry HTTP instrumentation and Sentry's span inference logic; preserves custom names by marking them with 'custom' source and storing in temp field which takes precedence over the actual name and gets deleted at the end
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TL;DR: This PR Adds
Sentry.updateSpanName()to reliably update span names in OpenTelemetry environments; prevents overwrites from both OpenTelemetry HTTP instrumentation and Sentry's span inference logic; preserves custom names by marking them with 'custom' source and storing in temp field which takes precedence over the actual name and gets deleted at the end"Why not use
span.updateName()?", the avid SDK user might ask. Here's why:In our Node SDK, most/all spans are created by OpenTelemetry instrumentation. OpenTelemetry has no concept of a transaction
sourceand only stores the name of the span in theSpaninstance. Some instrumentation, most importantly,@opentelemetry/instrumentation-httpstarts a span (in this case root span) and later on updates the name. In the http case, this update happens at the end of the request lifecycle. Consequently, any span name updates prior to this call, regardless of them coming from our SDK or from users, are overwritten.In addition to this limitation within Otel instrumentation, we also have our own span name, op and source inference logic which we apply when exporting the span to add Sentry-specific data (like a better span name, an op, a transaction source and additional data) to otel-generated spans. So even if Otel didn't call
updateName()in its instrumentation, user-madeupdateNamecalls to e.g. http.server spans were also overwritten by our logic.So we need some way of 1. bypassing our span inference logic and 2. ensuring a user-update span name has precedence over otel's span name updates.
1 we can achieve with setting the source attribute to
customand ensuring we don't change the span name if we encounter acustomsource.2 we can only achieve if we write the user-updated span name to temporary field on the span and apply it during our span name processing logic.
This is exactly what
updateSpanNamedoes:span.updateName()SEMANTIC_ATTRIBUTES_SENTRY_SOURCE: 'customto the spanFurther changes in this PR:
parseSpanDescriptioncustominparseSpanDescriptionspan.updateNamehas no effect on http.server spans, even if you set sourcecustomThis PR supersedes #14280 where I thought we could monkey-patch
span.updateNamedirectly to make updating the span name AND the source more consistent without a new top-level function. Turns out, we cannot do this because then, Otel instrumentation would also call the monkey-patched version ofupdateName, meaning we can no longer distinguish between user-made and otel-made span name updates.