feat(replay): Keep min. 30s of data in buffer & worker mode#7992
feat(replay): Keep min. 30s of data in buffer & worker mode#7992
Conversation
size-limit report 📦
|
9cc9311 to
1dc4778
Compare
1dc4778 to
68d21c3
Compare
68d21c3 to
1018103
Compare
|
This pull request has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you label it "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
|
This pull request has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you label it "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
|
We have higher priority bugs atm, so this is going to take a backseat while we address those. Whenever you pick this up again @mydea, can you update against develop? I'd like to run benchmarks to see how this affects memory usage. |
|
This issue has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you remove the label "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
|
Closing this for now, if we ever want to revisit this we can. |
This re-implements #7025 with a new strategy.
It only keeps min. 30s when using the compression worker (without the worker, the same strategy as now is used, only that it will keep up to 30s max). This may be acceptable, I think? We could also try to implement this for the event array buffer as well, but the question is if we want to do that or say "good enough" this way.
Probably needs a bit more manual testing as well, but wanted to put this up so we can talk about it at least.
Closes #6908