The store took a scope only when it opened and acted on it only at a full
sync, so a lower cap left old mail on the device until something else
forced a resync. Now the engine applies a changed scope first, without the
network, and once a day as the window moves on.
Also tell the page whether an account's file was there when it opened, so
it can notice a store the browser deleted.
- `calendar-sync.test.ts` now syncs with `days: null`: its old events test
checks the calendar's own two years, and the calendar follows the scope now
- `page-side.test.ts`: the fake worker answers an open with what it found,
as the real one does
An edit that removed an entry was dropped at flush, because a server
value with more keys counted as already applied. Other fixes in the same
path:
- the local copy after a flush is the server's read-back, never what was
sent, since Stalwart 1.0 stores a data: URI as a blob
- a delete or a newer edit after a lost response no longer reads as a
change on the server, and an edit made during a refused send stays
- a create only becomes a card with its uid if that card holds what was
sent, otherwise it is a refused conflict
- a refused or failed flush no longer stops contacts syncing
- request limits come from the session
- answers wait for the first full pass
- paging goes by anchor, so a deleted card doesn't make the next one
get skipped and swept
contacts.test.ts: "continues a stopped full sync" now checks the anchor
instead of position 2000, because the cursor no longer pages by position.
Adds a `calendar` area to the local store. It syncs calendars, participant
identities, events and tasks as masters, through CalendarEvent/changes,
and answers Calendar/get, CalendarEvent/query, /get and /set from SQLite
when the server can't be reached.
- A range query gets series in both client modes, with their overrides,
and the calendar store expands them as it does for an older server.
- The synthetic-id probe gets the verdict from the last sync, so a client
started offline behaves the same once the server is back.
- Create, edit, delete and RSVP queue in `calendar_pending`, one merged
row per event, and go out through `calendar.flush` or the next sync.
A create finds itself by uid after a lost response.
- A write the server refuses, or one on a value the server changed, goes
to `calendar.conflicts`.
- `lib/store/calendar/reminders.ts` lists upcoming alerts with keys that
don't depend on synthetic ids.
Linus Rath