Closed Lms24 closed 1 week ago
This issue has gone three weeks without activity. In another week, I will close it.
But! If you comment or otherwise update it, I will reset the clock, and if you remove the label Waiting for: Community
, I will leave it alone ... forever!
"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
Currently, all values in
Span._attributes
are merged withSpan.data
and put into thedata
attribute of a JSON span.Plan for v8: We use span attributes as a replacement for setting tags or dedicated fields onto a span. For example:
Span.op
(#10189)Span.origin
(#10260)http.status_code
tag (#10268) <-- here I'm still setting the tag as well (see below)The consequences:
jsonSpan.op
& `jsonSpan.data['sentry.op']jsonSpan.origin
& `jsonSpan.data['sentry.origin']span.context.trace
sentry.op
andsentry.origin
span.tags
are (would in the future be) only set onspan.data
http.status_code
tag <-- To avoid this, I ended up duplicating setting the tag and attribute for now in #10268Solution
I think as long as our backend doesn't handle picking specific keys from
span.data
(I have no idea what it does with these currently) to handle them like they were tags, we need to map back things to the original span JSON payloads.But how are we going to do this reliably?
sentry.op
andsentry.origin
can probably stay duplicated inspan.data
(?)sentry.op
andsentry.origin
don't need to be sent in trace context. But does it hurt us sending them still?span.tags
http.status_code
-->tag.http.status_code
? Might work for our internal tags but user tags?