Uh oh!
There was an error while loading. Please reload this page.
feat(core): Align Span interface with OTEL - #12898
Conversation
size-limit report 📦
|
Lms24
left a comment
There was a problem hiding this comment.
Do we want to go through despite the breaking change?
| /** @inheritdoc */ | ||
| public setAttribute(key: string, value: SpanAttributeValue | undefined): void { | ||
| public setAttribute(key: string, value: SpanAttributeValue | undefined): this { |
There was a problem hiding this comment.
Technically that's a breaking change 😬
Sure, 99% of our users will simply call span.setAttribute but maybe for some reason someone asserts on undefined being returned. Is there a concrete reason (e.g. someone running into this mismatch) we should consider breaking here? If not, I'd vote we don't change the return types of setAttribute(s) in v8 but happy to discuss this.
There was a problem hiding this comment.
This is not breaking unless somebody implements the SentrySpan interface, which is not really something we recommend anyone doing.
There was a problem hiding this comment.
Hmm maybe I'm missing something but this (including variations of working with the return type) seems like valid code to me:
Sentry.startSpan({},span=>{assert(span.setAttribute(...)===undefined)})I'm not saying this is a likely code path. We can make the call to technically break here. If we do, I'd prefer to extract the breaking aspect into a separate PR to revert more easily in case someone does write in.
There was a problem hiding this comment.
Widening return types is generally not considered semver major, but sever minor I believe.
There was a problem hiding this comment.
I'd say this is fine, we generally accept widening return types as non-breaking I believe, the potential for breaking here is extremely low 🤔
There was a problem hiding this comment.
Ok, I'll keep the change then?
| * @hidden | ||
| * @internal | ||
| */ | ||
| public recordException(_exception: unknown, _time?: number | undefined): void { |
There was a problem hiding this comment.
comment/unactionable: "recordException" is a very unfortunate function name for users seeing this method when interacting with the Sentry SDK 😬
(ignore this comment, I'm just fairly sure someone is gonna call it "accidentally" instead of captureException)
There was a problem hiding this comment.
Had the same thought! I had an idea that we could alias this to captureException. Maybe we should also make it very clear in the JS doc that captureException needs to be preferred.
There was a problem hiding this comment.
I had an idea that we could alias this to captureException
yeah this also crossed my mind. But I'd rather do it when it comes up to save on bundle size.
Uh oh!
There was an error while loading. Please reload this page.
| /** @inheritdoc */ | ||
| public setAttribute(key: string, value: SpanAttributeValue | undefined): void { | ||
| public setAttribute(key: string, value: SpanAttributeValue | undefined): this { |
fixes#12566