mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 20:42:43 +00:00
Every cached read in this app is about one health record, and nothing in the key factory said which one — there was only ever the signed-in account's. Once a browser can act on somebody else's, `["dashboard","snapshot"]` names two different answers and the cache cannot tell them apart. That is this repo's known cache-poison class, on health data, across two people. One line at the root rather than a dimension threaded through twenty-three key modules: a `queryKeyHashFn` that folds the record id into the cache identity of every entry. Key arrays are untouched, which is the part that matters — prefix invalidation and the import-time dependent-key bundles both match on the array and keep working. Prefixing the arrays would have broken every bundle silently. The hash is defence in depth. Switching is a full page reload, so the in-memory cache is empty on the other side of it; the layers that survive a reload are the IndexedDB snapshot and the service worker's data cache, and those are handled by refusing to write either while a switch is on, and by skipping the restore. Nothing of the owner's record ever reaches the disk of a delegate's device, so a stale scope marker can cost an empty restore and never another person's data. The persister's per-account binding read the account payload's id, which under a switch is the delegate in both states — it could not tell the two apart. It now asks the record scope, which can.