timescale.info#124 · Keep stored windows a page lets go of
- timeline-app
- pull request
- packages
Fixes the intermittent Firefox failure in `viewport-store-browser`, which just failed PR #121 and failed #114 and #117 before it. ## Cause `planSave` stored the page's current windows and **deleted every other stored window of the timeline** ("windows the page released"). Storage mirrored the page at the moment of each save. Any save made while the page held fewer windows than storage permanently deleted the rest: - after a hidden page releases windows and before it takes them back; - after the page's own cache let go of some under its limits. #121's failure shows the result. Storage held exactly the four windows covering the last view, which are the windows `release()` keeps, so the first view (0–20) could no longer be shown from storage. #114 and #117 fixed one timing path into this and a too-specific assertion. This removes the cause itself. ## Fix - A save adds the page's windows and deletes only windows of **other revisions** (or plugin sets) of the timeline. - A window the page has let go of stays stored for a later visit. - A new limit, `STORED_PER_REVISION = 64`, keeps the most recently saved windows of a revision. The existing 64 MiB total and 30-day keeping time still apply. - `docs/architecture.md` is updated. ## Tests - Unit tests: a released window stays stored while another revision's goes, and a new test covers the per-revision count. - `viewport-store-browser`: 8 of 8 in Firefox and 8 of 8 in Chromium in a one-CPU container. I couldn't reproduce the exact CI interleaving locally (40+ runs under CPU limits passed). The fix removes the only way storage can lose windows of the current revision, so it doesn't depend on that interleaving.
Sources
Open #124 · Keep stored windows a page lets go of in the timeline