Browser client tracing tries attaching wasm blobs to spans, exceeding envelope size

[brunohaid]

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

Load a piece of wasm code that gets attached to a tracing span.

Expected Result

It's possible to filter data.url, data.http.url and description with beforeSendSpan and/or beforeBreadcrumb, but the client should be smart enough to truncate instead of sending a payload it knows the backend won't accept.

Actual Result

The tracing library tries attaching wasm blobs like url: "data:application/octet-stream;base64,AGFzbQEAAAABqwVRYAF/AX9gAX8AYAJ/fwBgAn9/AX9g... as both data.url and data['http.url'] and GET data:application/octet-stream;base64,AGFzbQEAAAABqwVRY... as description, immediately blowing past envelope size limits resulting in a 400 response with envelope exceeded size limits for type 'event' .

Product Area

Ingestion and Filtering

Link

No response

DSN

No response

Version

No response

[linear]

ENG-4755 Browser client tracing tries attaching wasm blobs to spans, exceeding envelope size

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[linear]

NATIVE-111 Browser client tracing tries attaching wasm blobs to spans, exceeding envelope size

[linear]

JS-841 Browser client tracing tries attaching wasm blobs to spans, exceeding envelope size

[brunohaid]

See https://www.meso.cloud/plants/magnoliophyta/malvales/magnoliopsida/malvaceae/theobroma_cacao as example, both the Globe and Protein visualizations use WebGL wasm. Wait for first /logging POST (we tunnel through Cloudflare workers), see spans and breadcrumbs that are now manually ... [truncated] at 300 chars in payload, but would otherwise contain the entire compiled wasm code.

[Lms24]

Hey @brunohaid apologies for the late reply! This just found its way to the JS SDK team today.

Can you share some more information about your setup, including:

• Which SDK you're using + version
• Which framework you're using
• How to reproduce this
• To confirm: Base64 data urls make it into the http.url attributes of spans created by browserTracingIntegration?
• Can you share logs from beforeSendSpan and beforeSendTransaction?
• Can you confirm that the consequence for you was that the entire trace was dropped? Or just the span with the too large size?

I just want to make sure we fix the right thing in the right way. Regarding data truncation: SDKs currently do not truncate span attributes. Ideally, they don't have to do this because it seems like a perfect job for Relay (our ingestion service) to take care of in one place rather than the ~100 SDKs we maintain. I will discuss this internally how to proceed here.