eap: Handle type changes when normalizing attributes

[loewenheim]

There are a handful of deprecated attributes defined in sentry-conventions where the replacement has a different type. As of getsentry/sentry-conventions@c116335:

deviceMemory: string -> device.memory.estimated_capacity: integer (backfill)
hardwareConcurrency: string -> device.processor_count: integer (backfill)
ai.tools: string[] -> gen_ai.request.available_tools: string (backfill)
ai.responses: string[] -> gen_ai.response.text: string (backfill)
ai.texts: string[] -> gen_ai.input.messages: string (backfill)
ai.tool_calls: string[] -> gen_ai.response.tool_calls: string (backfill)
db.sql.bindings: string[] -> db.query.parameter.<key>: string (None)

In two of them we go from a string to an integer, in the others from a list of strings to a single string. Both of these cases are easy enough to handle during normalization:

• string -> integer: Parse the number
• string[] -> string: Concatenate the strings with ", "

However, this still raises the question of how we should handle this in the future: what if a type change is added for which it's not as obvious what we should do? Should we lint for this relay-conventions?

There is the further problem that in db.sql.bindings -> db.query.parameter.<key> we go from a single attribute to multiple attributes. This is academic at the moment because the attribute has no normalization defined right now (and possibly never will), but it's something to keep in mind.

[linear-code]

RELAY-240

[Dav1dde]

I think string -> number or the reverse are pretty obvious. I am not sure if doing automatic , concatenation (or the reverse) is a good idea, I think that choice should be made in conventions on a per attribute basis.

There is also the question how failures are handled what if something can't be converted to an integer?

I feel like these decisions can only be made in conventions and we can only provide a somewhat sensible default, if there is one.

[loewenheim]

Fair enough about the automatic concatenation—I was maybe jumping the gun there (in fact, for e.g. URL query strings this would clearly be wrong).

Failures seem pretty straightforward to me—if the conversion fails we annotate the new attribute accordingly. So if you send hardwareConcurrency: "five" then device.processor_count will be an "invalid value". But maybe I'm once again only thinking about simple cases.

[Dav1dde]

I think the semantics for errors haven't really been explored yet, currently we don't do any type validation for convention attributes, they may be defined as integer, but users (and SDKs) can freely send anything.