The user-data cache is keyed by server instance
(`iptvnator-server:cache:<instanceId>:<namespace>`): a tab still open on
the old backend after BACKEND_URL changed no longer writes over the new
server's cache, which the new tab's next edit would have sent there.
claimCache also removes the old owner's keys and the unscoped keys of
earlier builds.
touch(), which runs every 30 s, adopts closed tabs' saved writes once
this tab has read: a tab with nothing to sync never re-reads, so they
waited until a tab switch or reload.
UserDataStorage gains an optional ready(); the server storage resolves
it after its first read and rejects while that fails. A PWA backup
export awaits it, so a fresh browser whose /user-state read is slow or
failed cannot export empty favorites, history and positions.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The access token is stored with the instance id it was given for, and a
page reads it only for its own instance: a tab still open on the old
backend after BACKEND_URL changed no longer sends the new server's
token there. The API client hands every 401 to reportAccessDenied(),
which now also sends a page without a token for its instance to sign-in,
while one that holds its token back until the instance is checked keeps
it.
A closed tab's adopted edits carry `yields`: replayed, they change only
what is still as that tab saw it, so they never replace progress this
tab or another device saved since. The flag survives the journal.
The sync spec's fake server and memory storage move to a test-helpers
file to keep the spec under its line limit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- A server that answers as another backend URL or instance id than the
remembered one makes the browser forget the stored token, so server A's
token never reaches server B.
- The session installs its page-hide and heartbeat listeners before it
returns for sign-in, so a page holding another page load's writes still
marks itself closed on unload.
- Closed tabs are found by stale records only again: saved writes without
a record may belong to a running tab whose record storage refused, and
are left to that tab's own reload.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- The unconfirmed-writes registry stores each page load's record under
its own key (iptvnator-server:unconfirmed:<instance>:<page>), listed
through a new keys() on the user-data storage adapter, so tabs never
overwrite each other's records. Saved writes without a fresh record,
also when the record was lost, are adopted as a closed tab's (#1920).
- PwaService sends the stored server token on its raw fetch calls only
while server mode runs, and a backend that answers without server
storage makes the browser forget the token.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- PlaylistEffects.setFavorites$ applies the drag's order through
transformPlaylistFavorites (reorderFavorites): favorites added on another
device stay, ones removed there stay out.
- The remembered server matches the backend URL by origin and path
without trailing slashes, so /api and /api/ start offline in server
mode alike.
- Maps keyed by playlist id are built without a prototype (idMap), so an
id such as __proto__ is an ordinary key in the cache, conflict replays,
re-reads and tags.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ServerUserDataStorage records each successful delete; a re-read sent
before it drops the deleted playlist's entries and tags from the server's
answer (withoutDeleted), so a late answer cannot write the deleted
favorites and positions back into the cache.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A page that never read the server has no version tags, so an adopted
write went out unconditionally and replaced newer server data with its
cached value. Adopted edits now use the never-matching version when this
page knows none (and for a queued write without a tag), so the server
answers 412 and the edits are replayed on its value.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
When touch() finds that the previous page load no longer looks live, this
page may already have read and queued newer edits. Its saved writes and
early edits are now adopted like a closed tab's (their steps ahead of this
page's newer ones, queued at once) instead of restored as if this page
had just started, which replaced newer progress with older and parked
early edits that were never sent after the first read. Cache forgetting
moves into UserDataCache.forget().
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
When the close flag could not be saved (storage full), a reload took the
previous page load for a running duplicated tab and left its saved writes
unsent. The page now remembers that page load and its 30 s touch takes it
over as soon as its record is closed, stale or gone, so the session's
retry sends the writes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- A page marks its unconfirmed-writes record closed on pagehide (not into
the back-forward cache); a new page takes over the previous page load's
saved writes only when that record is closed, stale or missing, so a
duplicated tab, which copies sessionStorage, leaves the running tab its
writes.
- PlaylistsService.removeAll lets queued playlist writes land first and
makes writes issued meanwhile wait until it finished; the server store
refuses a document without an id.
- Moving browser data sets the explicit Stalker portal-mode flag on rows
from before it (withExplicitStalkerPortalFlag, now shared with
PlaylistsService).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PUT /v1/user-state/:namespace/:playlistId answers 404 playlist_missing
when the server has no such playlist, so an edit queued on another device
(including its conflict replay with If-None-Match: *) cannot recreate the
state of a playlist deleted meanwhile. The client drops such an edit and
its cache entry instead of retrying; page-hide writes report it as gone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- PlaylistEffects.updateFavorites$ applies the toggled channel through
transformPlaylistFavorites, on the favorites read at write time, instead
of writing the reducer's whole array: a conflict retry keeps another
device's favorites (#1919).
- Edits made before the first read on top of this tab's recovered unsent
write are appended to it as their own steps, so a removal of an item the
recovered write adds survives a conflict replay.
- Journal copies of earlier page loads kept because this page could not
save its own are removed once it can.
- adopt/extend move into server-user-data-adopt.ts over a small queue API
(unsent, isQueued, put); the queue exposes its tag map.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- A served copy carries the version it came from (a symbol property that
spreads keep and JSON drops), so a mutation of a portal document names
the version it was built on, not the latest read.
- A 401 for a token replaced since (a new sign-in) neither clears the new
token nor reports unauthorized, in the API client, the HttpClient
interceptor and PwaService's proxy calls.
- Moving browser data counts a browser user-data map that cannot be read
as a failure, so the move stays on offer.
- An edit made before the first read on top of this tab's recovered
unsent write is applied to that write, not to the server's value.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Every playlist mutation is sent on the version it was read at: the
payload's ETag, else the playlist's last read (portal documents have no
payload). Refused versions are tracked per playlist, so a conflict on
one never disables the check on another at the same revision. Imports
and start-up migrations (dbUpsertAppPlaylists) stay unconditional.
- A closed tab's adopted edits replay before this tab's queued ones, from
the base of its first step, so newer progress is not replaced by older.
- A reload or adoption removes the old page load's saved writes only when
this page saved its copy; each closed tab is adopted once per page.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ServerUserDataStorage remembers the map getItem handed out. When the
cache changed since (another tab saved, a re-read), a write applies only
the entries the caller changed to the current cache, so a map read
before another tab's save no longer reads as deleting that save. The
cache moves into UserDataCache.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Steps of a write whose answer was lost, of saved writes taken over after
a reload, and of a closed tab's saved edits are marked uncertain, so a
later edit never joins them: adding and then removing an item after a
lost answer still removes it.
- A closed tab's saved edits are queued ahead of this tab's own even when
the cache already shows them, so a conflict replays them too.
- The tag map moves into UserStateTags.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- A queued write keeps its edits as steps: an edit continuing the last one
joins it, one made behind a travelling write or on another tab's change
stays apart, and a conflict replays them in order. Saved writes and
early edits store the steps too.
- The instance probe treats any refusal but 404 (a proxy's 429 or 403) as
unreachable, so a browser keeps its remembered server.
- Cache reads that browser storage refuses fall back to memory, so a
re-read and later edits still work.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Unconfirmed writes and early edits are saved in localStorage per page
load; the tab remembers its page load in sessionStorage, so a reload
takes them over, and another tab replays a closed tab's writes once its
record is stale. Live tabs renew their record every 30 s.
- An edit made on another tab's unsent change, and an entry a re-read
keeps from the cache, are sent on a version no entry has, so the write
conflicts and is replayed instead of carrying another tab's change past
a later removal.
- Moving browser data counts the parental-lock step as failed while the
lock store cannot be read, so the move stays on offer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- An edit queued behind a travelling write keeps its own before → after
and carries the travelling write's edit as `prior`, also in the saved
writes. A conflict replays both in order, so adding and then removing a
favorite removes it whether or not the first write landed, and a lost
write is not dropped.
- Page-hide writes now report their new tag or a 412 like normal writes:
a confirmed one rebases the next edit, a conflict is replayed.
- After an offline start from a remembered instance, writes are held and
the retry only checks /instance before reloading, so saved writes never
reach another database behind the same address.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- A re-read that keeps an entry from the cache (another tab's or this
tab's unconfirmed value) no longer takes the server's tag for it, so the
next edit conflicts and is replayed instead of overwriting another
device's change.
- Page-hide writes behind a travelling one are taken from the queue when
it is answered, so its new version becomes their baseline.
- A playlist delete holds that playlist's user-data edits instead of
discarding them up front; only a successful delete drops them, a failed
one sends them as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- User-state entries carry a content tag; PUT/DELETE accept If-Match or
If-None-Match: * and answer 412 with the current value and tag. The PWA
sends each edit on the tag it read and replays it (before → after) on
the server's value after a conflict, so another device's change to the
same playlist's favorites or positions is kept instead of overwritten.
- The access token goes only to the backend URL (same origin and path),
never to another host or a sibling path.
- Deleting a playlist (or all) first drops its queued user-data edits and
waits for writes in flight, so none recreates deleted data.
- The migration copy writes on the tags it read.
- The write queue moves out of ServerUserDataStorage into
UserDataWriteQueue.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
