Serializer trimming improvements

[sentrivana]

Problem Statement

It's been coming up a lot in recent years that people are unhappy with the way our serializer auto-trims their events. The most common issues are that there is no indication in the UI that some part of the event was trimmed and that parts of objects important for debugging go missing.

As far as we know sentry-python is also the only SDK that actively trims events before sending.

Ingest will drop an event if it is too large, (see also #2223 (comment)) which should be made transparent to users (e.g. client reports) if it happens.

We've recently updated an option to skip trimming request bodies. This issue considers going one step further and removing the limits altogether, either optionally or in all cases.

Related Issues

• Do not trim large extra data? #377
• Show in the UI when Sentry truncates data sentry#68426 (moved to sentry)
• Prioritize certain parts of sentry issue information when performing truncation #1259
• Does this client truncate long strings and lists? #344
• Exclude dicts from context #335
• Introduce config for MAX_STRING_LENGTH #2121
• Indicate in the UI when an array or dictionary variable value has been truncated sentry#51998

Solution Brainstorm

• (add a client option to) disable trimming altogether
• consider if we need the serializer
• make sure that it's transparent to the user if ingest drops an event due to it being too large
• add a visual indicator to the UI that something was trimmed (if we keep the trimming)

[antonpirker]

I just talked to ingest at breakfast. What happens with big payloads:

• There is something in nginx that drops REALLY big payload. They where not sure if there will be an outcome for that.
• Then the envelope arrives at relay and a size check is done. Eventually dropping if too big (with outcome)
• There there is also an envelope item limit, eventually dropping the item.
• Then relay does some truncation.
• Then the rest of the processing