Ensure Span attributes are mapped to correct properties in JSON spans

[Lms24]

Currently, all values in Span._attributes are merged with Span.data and put into the data 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:

• Some fields are duplicated:
  • jsonSpan.op & `jsonSpan.data['sentry.op']
  • jsonSpan.origin & `jsonSpan.data['sentry.origin']
• New fields end up in span.context.trace
  • sentry.op and sentry.origin
  • Is this problematic or just unnecessary/redundant data?
• Entries in span.tags are (would in the future be) only set on span.data
  • http.status_code tag <-- To avoid this, I ended up duplicating setting the tag and attribute for now in #10268
  • Potentially a lot more tags as we remove deprecation ignores
  • Potentially all user-set tags once they migrate

Solution

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 and sentry.origin can probably stay duplicated in span.data(?)
• sentry.op and sentry.origin don't need to be sent in trace context. But does it hurt us sending them still?
• but tags should still be mapped to span.tags
  • do we need to prefix the attribute keys? e.g. http.status_code --> tag.http.status_code? Might work for our internal tags but user tags?

[getsantry[bot]]

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 🥀