Repository navigation
Replays rejected due to size limit exceeded. #12866
Description
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.
Activity
lforst commentedon Jul 11, 2024
@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 commentedon Jul 11, 2024
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 commentedon Jul 11, 2024
Another possible solution is to not inline the CSS and:
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)
cache the resource on our own infra -- adds infra complexity and costs, requires additional rrweb changes
Sammaye commentedon Jul 12, 2024
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
4 remaining items
mydea commentedon Mar 18, 2025
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 commentedon Mar 18, 2025
@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