We have higher per-span size limits for the new v2 spans than we have in our transaction-based event payload.
Today, many AI spans (and with them their whole transaction) are dropped because they can exceed size limits. We try to alleviate this via truncation, but this a) looses information and b) is not perfect and misses certain things, so the situation is still not ideal.
To fix this, we want to send such AI spans in a combined envelope:
If a transaction should be sent and we detect it contains AI spans,
… then we want to take the AI spans out of the spans array of the transaction event…
… and instead send these as v2 spans in a separate envelope item in the same payload
This should ensure that AI spans are not dropped.
Note: This means that on e.g. self hosted instances that do not support v2 spans things may be lost, but this is an acceptable downside for the time being.
Description shamelessly stolen from getsentry/sentry-javascript#20170
We have higher per-span size limits for the new v2 spans than we have in our transaction-based event payload.
Today, many AI spans (and with them their whole transaction) are dropped because they can exceed size limits. We try to alleviate this via truncation, but this a) looses information and b) is not perfect and misses certain things, so the situation is still not ideal.
To fix this, we want to send such AI spans in a combined envelope:
If a transaction should be sent and we detect it contains AI spans,
… then we want to take the AI spans out of the spans array of the transaction event…
… and instead send these as v2 spans in a separate envelope item in the same payload
This should ensure that AI spans are not dropped.
Note: This means that on e.g. self hosted instances that do not support v2 spans things may be lost, but this is an acceptable downside for the time being.
Description shamelessly stolen from getsentry/sentry-javascript#20170