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