Going offline now marks the instance unchecked: the token and writes
wait until /instance answers with this page's instance (another one
reloads the page). A replaced volume at the same address no longer gets
the old token and queued user-state writes on reconnect. The session
checks as soon as it goes offline, so a blip costs no retry interval.
A page restored from the back-forward cache whose record another tab
adopted meanwhile (its timers were frozen, so the record went stale)
reloads instead of sending those writes again after newer edits.
The Stalker playlist metadata migration also runs on server rows, once
per server: a desktop database copied to the server can predate it, and
its Stalker rows lacked isFullStalkerPortal.
The take-over and change-diff loops move out of the user-data facade,
and the adoption specs get their own file.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Startup waits for the first user-data read only a few seconds. ready()
now waits for a first read in flight without starting one (an offline
page is not held up) and tells whether one succeeded:
- PwaXtreamDataSource awaits it before reading favorites, recent items
and playback positions, so a new device whose /user-state read is slow
does not show empty lists or start playback without its resume point.
- A PWA backup export and restore fail while no read succeeded; the
restore stays parked, since its replacement lists would otherwise
merge into the server's (an empty favorites list changed nothing).
A page-hide keepalive write gets the request timeout: a server that
takes it and never answers no longer holds every later write, re-read
and delete behind it until reload.
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>
- ServerStorageStatusService.accessToken() returns the stored token only
while server mode runs on an instance this start verified. The API
client, the HttpClient interceptor and PwaService's raw fetch calls use
it, so after an offline start from a remembered instance no request
(including the /instance reachability check) carries the token to
whatever answers at that address, and a 401 then does not clear it.
- Sign-in remembers the server along with the token; when storage refuses
either, it reports SIGN_IN_STORAGE instead of reloading into a start
that would drop the token.
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>
- 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>
- 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>
- 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>
- Moving M3U favorites keeps URL favorites and anything the server cannot
resolve; only older channel ids are translated.
- Queued user-data edits are sent before the move writes combined values.
- A re-read that does not fit the cache keeps the old cache and baseline
together.
- A response body cut off after its headers counts as offline.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Moved playback positions are matched by content type and Xtream id and
name the server playlist.
- Page-hide writes report whether the server took them; refused ones go
back into the queue. Re-reads run one at a time.
- The access guard's 401 carries WWW-Authenticate: Bearer
realm="iptvnator"; the interceptor and PwaService's raw fetches turn it
into sign-in, so a token changed on the server is noticed on provider
calls too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Moving browser playlists matches them to the server's by id or source and
carries the legacy Xtream maps under the server id; it no longer goes
through the backup format, whose PWA export has no Xtream user data. A
partial move stays on offer.
- User-data batches go out in order, and a re-read keeps entries edited
while it was in flight.
- A keepPayload write keeps its cached copy only when the server replaced
the version its payload came from (new X-Replaced-ETag header).
- 502/503/504 from the proxy count as offline.
- The start-up screen lets the sign-in page through while a token is
required.
- Settings → Server offers a reload after a move.
- The probe detects Electron through RuntimeCapabilitiesService.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The @iptvnator/services/server-storage sub-entry keeps server mode out of
the eager services barrel.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
