Skip to content
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): Add updateSpanName helper function #14291

Open
wants to merge 11 commits into
base: develop
Choose a base branch
from

Conversation

Lms24
Copy link
Member

@Lms24 Lms24 commented Nov 14, 2024

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 source and only stores the name of the span in the Span instance. Some instrumentation, most importantly, @opentelemetry/instrumentation-http starts 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, ob and source inferral 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-made updateName calls to e.g. http.server spans were also overwritten by our logic.

So we need some way of 1. bypassing our span inferral 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 custom and ensuring we don't change the span name if we encounter a custom source.
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 updateSpanName does:

  • update the span name via span.updateName()
  • add SEMANTIC_ATTRIBUTES_SENTRY_SOURCE: 'custom to the span
  • add a temporary attribute with the provided name to the span

Further changes in this PR:

  • Ensure we use the span name from temporary attribute if provided in parseSpanDescription
  • Ensure we respect source custom in parseSpanDescription
  • Delete the temporary attribute when creating the transaction envelope (no need to send this)
  • Add a bunch of unit and integration tests for the newly added function.
  • Also add two unit tests showing that span.updateName has no effect on http.server spans, even if you set source custom

This PR supersedes #14280 where I thought we could monkey-patch span.updateName directly 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 of updateName, meaning we can no longer distinguish between user-made and otel-made span name updates.

Copy link
Contributor

github-actions bot commented Nov 14, 2024

size-limit report 📦

Path Size % Change Change
@sentry/browser 22.8 KB +0.16% +35 B 🔺
@sentry/browser - with treeshaking flags 21.57 KB +0.19% +41 B 🔺
@sentry/browser (incl. Tracing) 35.31 KB +0.11% +38 B 🔺
@sentry/browser (incl. Tracing, Replay) 72.03 KB +0.05% +35 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags 62.41 KB +0.06% +36 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas) 76.34 KB +0.05% +35 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback) 89.19 KB +0.05% +39 B 🔺
@sentry/browser (incl. Feedback) 39.96 KB +0.08% +31 B 🔺
@sentry/browser (incl. sendFeedback) 27.45 KB +0.12% +33 B 🔺
@sentry/browser (incl. FeedbackAsync) 32.26 KB +0.12% +37 B 🔺
@sentry/react 25.56 KB +0.16% +41 B 🔺
@sentry/react (incl. Tracing) 38.27 KB +0.1% +38 B 🔺
@sentry/vue 26.96 KB +0.14% +37 B 🔺
@sentry/vue (incl. Tracing) 37.15 KB +0.13% +48 B 🔺
@sentry/svelte 22.94 KB +0.16% +36 B 🔺
CDN Bundle 24.22 KB +0.37% +90 B 🔺
CDN Bundle (incl. Tracing) 37.13 KB +0.23% +86 B 🔺
CDN Bundle (incl. Tracing, Replay) 71.8 KB +0.12% +86 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) 77.15 KB +0.11% +86 B 🔺
CDN Bundle - uncompressed 70.97 KB +0.35% +252 B 🔺
CDN Bundle (incl. Tracing) - uncompressed 110.18 KB +0.23% +252 B 🔺
CDN Bundle (incl. Tracing, Replay) - uncompressed 222.7 KB +0.12% +252 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed 235.92 KB +0.11% +252 B 🔺
@sentry/nextjs (client) 38.39 KB +0.12% +45 B 🔺
@sentry/sveltekit (client) 35.9 KB +0.14% +50 B 🔺
@sentry/node 134.55 KB +0.15% +206 B 🔺
@sentry/node - without tracing 96.42 KB +0.19% +184 B 🔺
@sentry/aws-serverless 106.66 KB +0.17% +180 B 🔺

View base workflow run

@Lms24 Lms24 force-pushed the lms/feat-span-updatename-wrapper branch from 70674de to c7b6718 Compare November 14, 2024 14:58
Copy link

codecov bot commented Nov 14, 2024

❌ 2 Tests Failed:

Tests completed Failed Passed Skipped
653 2 651 30
View the top 2 failed tests by shortest run time
span-decorator.test.ts Transaction includes span and correct value for decorated sync function
Stack Traces | 0.059s run time
span-decorator.test.ts:39:5 Transaction includes span and correct value for decorated sync function
span-decorator.test.ts Transaction includes span and correct value for decorated async function
Stack Traces | 0.522s run time
span-decorator.test.ts:4:5 Transaction includes span and correct value for decorated async function

To view more test analytics, go to the Test Analytics Dashboard
Got feedback? Let us know on Github

@Lms24 Lms24 marked this pull request as ready for review November 14, 2024 16:23
@@ -172,6 +296,26 @@ describe('descriptionForHttpMethod', () => {
source: 'url',
},
],
[
'works with prefetch request',
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just an additional test I added because we didn't test the condition to add .prefetch to the op.

@@ -91,6 +91,14 @@ export function createEventEnvelope(
// have temporarily added, etc. Even if we don't happen to be using it at some point in the future, let's not get rid
// of this `delete`, lest we miss putting it back in the next time the property is in use.)
delete event.sdkProcessingMetadata;
try {
// @ts-expect-error - for bundle size we try/catch the access to this property
delete event.contexts.trace.data._sentry_span_name_set_by_user;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

m: Instead of doing this here, can we handle this in otel? We have a function removeSentryAttributes there already that gets rid of "internal" attributes, IMHO we can just add to this? :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unfortunately I'm afraid we have to do this in core because people can call updateSpanName in browser SDKs as well.

if (shouldSkipTracingTest()) {
sentryTest.skip();
}
sentryTest(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this PR supposed to include changes to browser tracing (tests)? 😅

Copy link
Member Author

@Lms24 Lms24 Nov 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes. We have to export updateSpanName also from browser for people who'd use this function in code that runs both on browser and on server. So I added an integration test for it. This test, I adjusted. The changes look scarier in the diff than they actually are. Just updated the name and added some additional assertions.

// if http.method exists, this is an http request span
// eslint-disable-next-line deprecation/deprecation
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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to do this initially but then we'd potentially lose the inferred op, no?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants