Inconsistent normalization of Transaction/Span data

Summary

• Transaction.data is too easily truncated
• Span.data is never normalized

Details

Introduction

The JS SDKs have a feature to normalize events before serialization that prevents serializing very deeply nested objects.

https://github.com/getsentry/sentry-javascript/blob/4e552ec0dc7d96a249d0f0ab7df7f4796623a521/packages/types/src/options.ts#L97-L106

This is a great feature, however it does not apply consistently to Transaction/Span data.

Problem

• Transaction data is stored in Event.contexts.trace.data.
• Span data is stored in Event.spans[].data.

Unlike for breadcrumbs that normalization applies only to the .data property of each breadcrumb, normalization is applied to Event.contexts as a whole:

https://github.com/getsentry/sentry-javascript/blob/4e552ec0dc7d96a249d0f0ab7df7f4796623a521/packages/core/src/baseclient.ts#L303-L323

What that means in practice is that, without changes to normalizeDepth, it is impossible to store objects in Transaction.data and have them sent to Sentry. Transaction.data is indirectly forced to be a flat object.

Users unaware of normalizeDepth can hack it and JSON.stringify the values they send, but that gives worse user experience 2 times:

1. Seeing [Object] where the expect some data; fix the frustration with JSON.stringify and then
2. Having a string instead of proper JSON means we cannot pretty print the value in the UI:

Manually stringified object

Regular JSON object

Possible solutions

Considering that all documented context types are flat objects, it is possible that we could relax the way how normalization applies to Event.contexts.

The new contexts.trace is the only key under contexts that may have nested objects under contexts.trace.data.

Option 1: liberal

An obvious option to consistently handle Transaction/Span data is to remove normalization from contexts altogether.

Option 2: restrictive

Alternatively, normalization should:

• not apply to contexts as a whole; and
• apply only to contexts.trace.data; and
• apply to spans[].data.

Option 3: Improve Contexts normalization

• not apply to contexts as a whole; and
• Instead, walk through all the keys in contexts and apply it to that values of the key

edit: this is not an option to fix the inconsistency, it would still treat Transaction.data and Span.data differently.

[HazAT]

@dashed nope

[HazAT]

Option 3️⃣ Reasoning: Option 1 changes the whole behavior of the SDK again -> We can drop whole normalization once we decided what to do with the payload issue.

Option 2 I don’t want to apply this now to span.data since it wasn’t there in the first place

Option 3 It fixes the current problem while leaving most of the stuff the same as it was before