Currently, some Sentry frontend logic depends on hard-coded, deprecated attributes like here. SDKs may stop sending these at any time in favour of the replacing attributes which will break functionality right now.
While we can handle the case of querying for deprecated attributes via Snuba's coalescing, the same does not apply for telemetry returned by the API where frontend logic depends on attributes. We do not return deprecated versions of an attribute if the telemetry item doesn't contain it. Furthermore, Relay's backfilling/normalization also does not apply here, since it only adds the non-deprecated replacement attribute to telemetry that originally gets sent with a deprecated attribute (e.g. by SDKs).
I had claude audit the frontend code base for references of deprecated attributes with the following criteria:
- the attribute is deprecated
- logic depends on this attribute (e.g. rendering of an element if an attribute is present/has a certain value)
- said logic only checks the deprecated attribute and not the stable replacement
This returned the following list:
| Deprecated attribute |
Locations |
mcp.tool.name |
views/dashboards/utils/prebuiltConfigs/ai/mcpTools.ts:16,31,33,51,53,71,73,96,110,141,142
views/dashboards/utils/prebuiltConfigs/ai/mcpOverview.ts:16,98,100,106
views/performance/newTraceDetails/traceDrawer/details/highlightedAttributes.tsx:260 |
mcp.prompt.name |
views/dashboards/utils/prebuiltConfigs/ai/mcpPrompts.ts:16,31,33,51,53,71,73,96,110,141,142
views/dashboards/utils/prebuiltConfigs/ai/mcpOverview.ts:18,152,154,160
views/performance/newTraceDetails/traceDrawer/details/highlightedAttributes.tsx:276 |
mcp.transport |
views/dashboards/utils/prebuiltConfigs/ai/mcpOverview.ts:70,71,73
views/performance/newTraceDetails/traceDrawer/details/highlightedAttributes.tsx:284 |
mcp.tool.result.content |
views/performance/newTraceDetails/traceDrawer/details/span/eapSections/mcpOutput.tsx:13,34 |
gen_ai.usage.input_tokens.cached |
views/dashboards/utils/prebuiltConfigs/ai/aiAgentsModels.ts:79,85,124,135 |
gen_ai.usage.output_tokens.reasoning |
views/dashboards/utils/prebuiltConfigs/ai/aiAgentsModels.ts:81,87,126,137 |
code.filepath |
views/insights/common/components/spanDescription.tsx:58,112
views/performance/newTraceDetails/traceDrawer/details/span/eapSections/description.tsx:160 |
code.lineno |
views/insights/common/components/spanDescription.tsx:59,113
views/performance/newTraceDetails/traceDrawer/details/span/eapSections/description.tsx:161 |
db.system |
views/insights/common/components/spanDescription.tsx:57,111
views/insights/common/components/fullSpanDescription.tsx:45,54
views/performance/newTraceDetails/traceDrawer/details/span/eapSections/description.tsx:81 |
performance.timeOrigin |
views/performance/newTraceDetails/index.tsx:124
views/performance/newTraceDetails/traceModels/traceTreeNode/baseNode.tsx:388 |
We need to fix these cases in the frontend by looking up attributes in a way that we don't just depend on one attribute but walk the attribute chain. To future-proof ourselves here, I'd recommend also not relying on the currently stable attribute but using the approach proposed here: getsentry/sentry-conventions#496. I have a PR to implement this in conventions which isn't merged yet. I can expedite work on this if it's helpful.
Currently, some Sentry frontend logic depends on hard-coded, deprecated attributes like here. SDKs may stop sending these at any time in favour of the replacing attributes which will break functionality right now.
While we can handle the case of querying for deprecated attributes via Snuba's coalescing, the same does not apply for telemetry returned by the API where frontend logic depends on attributes. We do not return deprecated versions of an attribute if the telemetry item doesn't contain it. Furthermore, Relay's backfilling/normalization also does not apply here, since it only adds the non-deprecated replacement attribute to telemetry that originally gets sent with a deprecated attribute (e.g. by SDKs).
I had claude audit the frontend code base for references of deprecated attributes with the following criteria:
This returned the following list:
mcp.tool.nameviews/dashboards/utils/prebuiltConfigs/ai/mcpTools.ts:16,31,33,51,53,71,73,96,110,141,142views/dashboards/utils/prebuiltConfigs/ai/mcpOverview.ts:16,98,100,106views/performance/newTraceDetails/traceDrawer/details/highlightedAttributes.tsx:260mcp.prompt.nameviews/dashboards/utils/prebuiltConfigs/ai/mcpPrompts.ts:16,31,33,51,53,71,73,96,110,141,142views/dashboards/utils/prebuiltConfigs/ai/mcpOverview.ts:18,152,154,160views/performance/newTraceDetails/traceDrawer/details/highlightedAttributes.tsx:276mcp.transportviews/dashboards/utils/prebuiltConfigs/ai/mcpOverview.ts:70,71,73views/performance/newTraceDetails/traceDrawer/details/highlightedAttributes.tsx:284mcp.tool.result.contentviews/performance/newTraceDetails/traceDrawer/details/span/eapSections/mcpOutput.tsx:13,34gen_ai.usage.input_tokens.cachedviews/dashboards/utils/prebuiltConfigs/ai/aiAgentsModels.ts:79,85,124,135gen_ai.usage.output_tokens.reasoningviews/dashboards/utils/prebuiltConfigs/ai/aiAgentsModels.ts:81,87,126,137code.filepathviews/insights/common/components/spanDescription.tsx:58,112views/performance/newTraceDetails/traceDrawer/details/span/eapSections/description.tsx:160code.linenoviews/insights/common/components/spanDescription.tsx:59,113views/performance/newTraceDetails/traceDrawer/details/span/eapSections/description.tsx:161db.systemviews/insights/common/components/spanDescription.tsx:57,111views/insights/common/components/fullSpanDescription.tsx:45,54views/performance/newTraceDetails/traceDrawer/details/span/eapSections/description.tsx:81performance.timeOriginviews/performance/newTraceDetails/index.tsx:124views/performance/newTraceDetails/traceModels/traceTreeNode/baseNode.tsx:388We need to fix these cases in the frontend by looking up attributes in a way that we don't just depend on one attribute but walk the attribute chain. To future-proof ourselves here, I'd recommend also not relying on the currently stable attribute but using the approach proposed here: getsentry/sentry-conventions#496. I have a PR to implement this in conventions which isn't merged yet. I can expedite work on this if it's helpful.