Skip to content

fix(settings): pick up changes made in another tab - #76

Merged
htcom-code merged 1 commit into
mainfrom
fix/settings-cross-tab-sync
Oct 12, 2026
Merged

htcom-code merged 1 commit into
mainfrom
fix/settings-cross-tab-sync

Conversation

@htcom-code

Copy link
Copy Markdown
Owner

Why

Every pc: key is shared by all tabs of the console, but each tab read them once at mount and never listened for the storage event. Lowering retention in one tab left another pruning the same IndexedDB to the old limit until it was reloaded, so the tab with the higher limit kept counting rows the other had already evicted.

Key Read by Cost of a stale value
pc:retention, pc:evictionFactor useSettings Storage: two tabs prune one IndexedDB to different limits
pc:pageSize, pc:sampleDelayMs useSettings Behaviour drifts between tabs
pc:metricsSort usePersistentState Display only
pc:theme useTheme Display only

What

  • subscribeStored(keys, onChange) in use-persistent-state.ts listens for storage events on those keys. A null key means localStorage.clear(), and events from sessionStorage are ignored.
  • useSettings reloads and re-validates all four settings on any of their keys. When nothing changed it keeps the old object, so effects keyed on settings do not restart. A save writes four keys and can arrive as four events; each one re-reads everything, so the tab ends up with the last value of each.
  • usePersistentState picks up its key the same way, which covers pc:metricsSort. useTheme now builds on it for pc:theme, and the OS preference is still queried only when nothing is stored.

When a changed limit applies

From the next batch. The trace store reads its settings at eviction time, so an eviction already in progress finishes on the limit it started with. A new retention-limit scenario pins this: the limit drops from 8 to 6 between batches and the next arrival prunes to 6.

Verification

  • 10 new tests (9 cross-tab, 1 retention). With the three hooks reverted, 5 of the 9 cross-tab tests fail. The other 4 are guards (validation, object identity, sessionStorage, unmount) and pass either way.
  • Two browser tabs on the dev server: a write in one tab switched the other tab's theme, and its settings dialog showed retention 120000 and factor 4×, with no reload.
  • npm run lint: 7 warnings, the same set as main
  • npm test: 18 files, 212 tests pass

Every pc: key is shared by all tabs of the console, but each tab read
them once at mount and never listened for the storage event. Lowering
retention in one tab left another pruning the same IndexedDB to the old
limit until it was reloaded, so the tab with the higher limit kept
counting rows the other had already evicted.

- subscribeStored() listens for storage events on given keys (a null
  key is localStorage.clear()); events from sessionStorage are ignored
- useSettings reloads and re-validates all four settings on any of
  their keys, and keeps the old object when nothing changed so effects
  keyed on settings do not restart
- usePersistentState picks up its key the same way, which covers
  pc:metricsSort, and useTheme now builds on it for pc:theme. The OS
  preference is still queried only when nothing is stored
- A changed limit takes effect from the next batch: the trace store
  reads its settings when it evicts, so an eviction already under way
  finishes on the limit it started with. A new retention-limit scenario
  pins that
- 10 new tests; with the three hooks reverted, 5 of the 9 cross-tab
  tests fail (the other 4 are guards that pass either way)
- Checked with two browser tabs: a write in one switched the other's
  theme and showed retention 120000 / factor 4x in its settings dialog
  without a reload
- Gates: lint clean (same 7 warnings as main), 212 tests pass

Tags: #settings #storage

Co-Authored-By: htjulia <htjulia1@gmail.com>
@htcom-code
htcom-code merged commit e140b02 into main Oct 12, 2026
4 checks passed
@htcom-code
htcom-code deleted the fix/settings-cross-tab-sync branch October 12, 2026 02:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant