Uh oh!
There was an error while loading. Please reload this page.
feat(core): Add updateSpanName helper function - #14291
Conversation
size-limit report 📦
|
70674de to
c7b6718Compare❌ We are unable to process any of the uploaded JUnit XML files. Please ensure your files are in the right format. |
| }, | ||
| ], | ||
| [ | ||
| 'works with prefetch request', |
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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| 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); |
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?
There was a problem hiding this comment.
I wanted to do this initially but then we'd potentially lose the inferred op, no?
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
32d395d to
5b42422Compare5b42422 to
1c71162CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
adee375 to
24e8320CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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
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.