feat(core): Add span serialization utilities#19140
feat(core): Add span serialization utilities#19140Lms24 merged 11 commits intolms/feat-span-firstfrom
Conversation
This PR adds utilities for serializing spans to the new V2 format: - `spanToV2JSON`: Converts a span to SerializedSpan (V2 format) - `getV2SpanLinks`: Converts span links with serialized attributes - `getV2StatusMessage`: Converts status to 'ok' | 'error' - `INTERNAL_getSegmentSpan`: Renamed from getRootSpan (with alias kept) These utilities are needed for the span streaming feature and will be used by subsequent PRs to serialize spans before sending. Co-authored-by: Cursor <cursoragent@cursor.com>
Codecov Results 📊Generated by Codecov Action |
size-limit report 📦
|
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
|
I am now a little confused if it is |
Co-authored-by: Jan Peer Stöcklmair <jan.peer@sentry.io>
| * of SDK code. If you need to get a JSON representation of a span, | ||
| * use `spanToV2JSON(span)` instead. | ||
| */ | ||
| public getStreamedSpanJSON(): StreamedSpanJSON { |
There was a problem hiding this comment.
To make this even more visible that this is an internal API: Should this maybe prefixed with _INTERNAL_?
There was a problem hiding this comment.
Users should never interact with SentrySpan directly but leave it up to start*Span* APIs which kind of Span (as in interface) they get back or work with.
I oriented myself here primarily on the already existing getSpanJSON method. In light of keeping the name short for bundle size, I'd tend to keep it that way, unless you think we should still do it?
Fully understandable! I removed a bunch of the remaining v2JSON jargon.
|
|
Not sure if a mixed jargon is helping. Especially when should we use v2 vs streaming. However, merging this in won't harm. Internally we can always rename (it's just the muscle memory which I'm worried about) |
|
ok you convinced me. I'll go with "streamedSpan" everywhere then. Will make some changes to this PR and open another one to adjust the envelope type names |
This PR adds span JSON conversion and serialization helpers for span streaming:
spanToStreamedSpanJSON: Converts aSpaninstance to a JSON object used as intermediate representation as outlined in feat(core/spans): Add span v2 and envelope type definitions #19100SentrySpan::getStreamedSpanJSONmethod to convert our own spansspanToJSONworks today.spanJsonToSerializedSpan: Converts aStreamedSpanJSONinto the finalSerializedSpanto be sent to Sentry.This PR also adds unit tests for both helpers.
ref #17836