-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replay "message size too large" error #23703
Comments
The new asset stuff from rrweb might help a lot with sending the inlined CSS in a different way rrweb-io/rrweb#1475 |
Does this issue have anything to do with |
Hey @sudo-eugene, Normally that's not the issue here. The best bet is to report the problem using the in-app support flow since that lets us look into you recordings specifically to see what's best. Ideally if you can include example recordings that'd be awesome |
@pauldambra this doesn't seem to be an issue in my PH cloud instance. It's only on my Self-Hosted instance that this happens. The issue report is, for reasons I understand, not available in the self-hosted version, hence my post here. |
Ah, it's really hard to debug self-hosted since everyone's setup can vary so much. You can see in this issue the reasons we see this trigger. With large data urls and large amounts of CSS being the next largest un-addressed items. |
Yes I suspect the CSS could be an issue our side. Could this potentially be due to inline CSS, or css files, or both? Is there a way to disable/exclude CSS that I know won't be of value in our recordings? |
@sudo-eugene we mostly recommend to people with very large CSS bundles that they skip inlining it. This can be done when initializing the SDK:
Just so you know, this will mean that the files will be fetched during playback. If there are no longer available or have changed since capture your recordings might be unstyled |
Just FYI: Sentry doesn't have any issues capturing same sessions |
I've added all of these and still getting the error. I'll keep debugging to see if I can find anything, or get a base version working
|
@sudo-eugene hmm sounds like it's not your CSS in that case. Would you mind opening a support ticket in-app or emailing me directly (david at posthog) so I can look into the specifics of your account |
Same problem to self hosted posthog But still see "This session recording had recording data that was too large and could not be captured. This will mean playback is not 100% accurate." |
Hey @flynet70 are you running the latest posthog including posthog-js v 1.166.x? We're consistently improving these ingestion routes (or trying to :)) |
@pauldambra thanks for answer! Yes. I upgraded via posthog-js Session replay works on main domain but 'too large' when I redirect to subdomain (billing system) But when i switch to cloud (api_host:'https://eu.i.posthog.com') - everything works well. Session replay works in billing subdomain too. What is difference? |
I though perhaps is was the Kafka message size limit, so I set this in my
|
@pauldambra |
I agree the next thing to try would be to increase message size over kafka. Assuming the kafka deployment is updated to accept larger messages you also need to set an environment variable to let the capture API know it's ok to ingest larger messages
|
@flynet70 @pauldambra I added the Thanks @pauldambra for the pointer. Here's the docker-compose.yml:
|
awesome... i'm going to close this so folk coming by see the resolution (although internally we're always working on improving this!) |
Bug Description
We see these for multiple reasons
We can't ingest them
When we can't ingest a recording snapshot the chance of an unplayable recording is high
We need to minimise these
Kafka checks the size of a message before it compresses it so we need to be under 10MB un compressed to be ingestible
We're gathering samples of these messages so that we can identify improvements
TODO
only works for updated clients
### works for all clients
The text was updated successfully, but these errors were encountered: