sentry-javascript
sentry-javascript copied to clipboard
getsentry
Keep min. 30 seconds for replay in error mode
Currently, when in error mode, we keep up to 60 seconds of replay recording for when an error happens.
Basically, what happens is:
- rrweb is instructed to do a full checkout every 60 seconds
- The event buffer will generally discard anything buffered before when it receives a full checkout
- When an error occurs, we send the whole buffer
- This means we send anything from 0-60 seconds of replay data
IMHO this can be unexpected (it was unexpected to me, I thought it would always keep the last 60s 😅 ). I propose that we change this to keep a min. of 60 seconds (except at the very beginning of the replay, of course. So we'd send anywhere from 60-120 seconds of replay data.
Hi, I am interesting in this replay and in the error mode. I am looking the different resources and it is quite a lot to get a full understanding. The error record solves a real problem, sometimes with failures you get the final state before it crash and you wonder how the client came to produce this state. Now I am wondering if we could configure the buffer range, could we keep 5min of buffer rather than 1min?
Hi, I am interesting in this replay and in the error mode. I am looking the different resources and it is quite a lot to get a full understanding. The error record solves a real problem, sometimes with failures you get the final state before it crash and you wonder how the client came to produce this state. Now I am wondering if we could configure the buffer range, could we keep 5min of buffer rather than 1min?
Currently, this is not possible. We are not likely to allow keeping such a long time in buffer, because it may become unfeasible to actually send so much data at once - the recording may be too large then and rejected by our API.
In what scenarios would 30-60 seconds of recording not be sufficient to debug an issue? Would be interesting to have some concrete use cases that would need this.
I was reflecting, if this is 30-60 sec of data yes it would be enough but if this is sparse like 1 click 15sec nothing 1 click 15sec nothing then we do not get enough value from the session. I dont know if buffer size or interaction/dom changes count could be the range of what is sent.
Maybe like min(5min session, 200 dom changes, 30 user interactions, max buffer size) I know it feels really abstract, I hope you can see what I mean, a user is not a constant and can do nothing for a moment and then click on something and boom.
Thanks for the explanation! Yeah, I think I see what you mean. We'll take this into consideration with our planning. Priority here is work to ensure we capture at least 30s before, we started some work on this some time ago that I need to revisit and update a bit - will keep this issue updated accordingly!
This would be very welcome - we always run in error mode and often see replays starting exactly when the error occurs - completely leaving out important context (API calls etc) that lead up to it. This unfortunately greatly limits the usability of replays for troubleshooting.
Could we keep two buffers of 15 instead? And instead of throwing away the old buffer once it's full, we keep it around and alternate which one is thrown away?
Replay: 0..15 seconds -> buffer A 15..30 seconds -> buffer B (30 seconds worth of data stored. If error happens within this time slot, we'd have buffer A + N seconds within this timeframe) Buffer A cleared (if error happens now, we'd send only buffer B, 15 seconds worth of recording data) 30-45 -> buffer A Buffer B cleared ..