Replays rejected due to size limit exceeded.

[rodolfoBee]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/browser

SDK Version

8.17.0

Framework Version

No response

Link to Sentry event

No response

SDK Setup/Reproduction Example

No response

Steps to Reproduce

CSS files are inlined in the replays segments, when this file is large enough it can easily make the segment reach the size limit specially in buffer mode. When the limit is reached, the following logs are printed in the console and the replay is dropped:

logger.js:75 Sentry Logger [info]: [Replay] Stopping Replay triggered by addEventSizeExceeded
logger.js:75 Sentry Logger [info]: [Replay] Destroying compression worker
logger.js:75 Sentry Logger [log]: Adding outcome: "internal_sdk_error:replay"

No workarounds at the moment.

Expected Result

The size of the CSS file does not affect the the ability of the SDK sending the replay. The replay is sent to Sentry and the server can render the recording with CSS.

Actual Result

Replays are dropped and marked as SDK internal error in the client reports.

[lforst]

@billyvg @mydea What was the decision-making behind this? Intuitively there seems no real way out of the situation except for increasing the limit but obv we can't do that ad infinitum.

[mydea]

A possible solution would be to split the event into multiple events/segments before we send it (ensuring each is below the limit), but this is rather complex, so not sure if we want to go down the road.

Another solution, as @lforst pointed out, is also to increase the limit (a bit?), but also not sure if we want to/can do that!

[billyvg]

Another possible solution is to not inline the CSS and:

1. load the resource as defined in HTML (e.g. load from user's CDN). This has its own drawbacks (e.g. broken CSS if resource is removed, CSS can reflect what it is currently in production and not what the user saw at time of replay)

2. cache the resource on our own infra -- adds infra complexity and costs, requires additional rrweb changes

[Sammaye]

One other option is I use releases and upload my assets to release, you could argue if I have an active release and source files you pick from those, that way you can trim the replay down as well removing assets and stuff

[chargome]

related to #13059

[bruno-garcia]

For reference: The max size of a segment today is 20MB uncompressed

We want to get some stats how often we drop due to max size.

• TODO: @bruno-garcia get the data

Some thoughts to improve this:

• Allow users opt-in to load their CSS from their server instead of inlining CSS. One complexity here is CORS
• Pulling CSS file from uploaded release assets
• Be clear on what the limitations we impose. Say: We only allow websites with a full checkout smaller than X MB (say today, 20 MB)

[mydea]

Is there anything we want to/can do about this in the new future? Or are we OK with the status quo, in which case I'd close this issue.

[chargome]

@mydea hosting the user's css assets would be the preferred solution as this would solve some other issues as well. For a more immediate solution there is a WIP pr for detecting duplicate mutations which could also help