Uh oh!
There was an error while loading. Please reload this page.
feat(replay): Keep min. 30s of data in buffer & worker mode - #7992
Conversation
size-limit report 📦
|
9cc9311 to
1dc4778Compare1dc4778 to
68d21c3Compare68d21c3 to
1018103CompareThis 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 🥀 |
billyvg
commented
Aug 9, 2023
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 🥀 |
mydea
commented
Dec 19, 2023
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