# DB Sync Status

This document covers the mail-to-database sync layer only, not the UI.

## Implemented features

### JMAP

- JMAP accounts can be stored in the database.
- JMAP endpoint discovery is implemented.
- JMAP connection testing is implemented.
- `sync_state` table stores server-side state tokens per (account, resource type).
- `pending_changes` table provides a protocol-agnostic outbound mutation queue.
- `JmapClient` fetches the JMAP Session object, extracts `apiUrl` and `accountId`,
  and provides a `call()` helper for API requests.
- `syncMailboxes` for JMAP: first run uses `Mailbox/get`; subsequent runs use
  `Mailbox/changes` with the stored state token.
- `syncEmails` for JMAP: first run uses `Email/query` + `Email/get`; subsequent runs
  use `Email/changes`. Chains both calls in a single API request via `#ids` back-reference.
- `Email/query` pagination: cursor-based loop with `position` offset and `calculateTotal`
  handles mailboxes larger than 500 emails.
- JMAP background sync worker (`_JmapAccountSync`): session → flush outbound queue →
  syncMailboxes → syncEmails per mailbox → 30 s poll → repeat. Exponential backoff
  5–300 s on failure.
- Local mutations (flag, move, delete) on JMAP accounts are written to `pending_changes`
  with an optimistic local update. `flushPendingChanges` drains the queue via `Email/set`
  at the start of each sync cycle.
- Email bodies are fetched on demand via `Email/get` with `bodyValues` and cached in
  `email_bodies` so subsequent opens are instant.
- `syncEmails` fetches `bodyValues` during the sync pass so bodies are cached without
  a separate on-demand fetch.
- `flushPendingChanges` passes `ifInState` to every `Email/set`; a `stateMismatch`
  response clears the local checkpoint and triggers a full re-sync before retrying.
- **JMAP send**: outgoing mail uses `EmailSubmission/set` when the server advertises
  the submission capability; falls back to SMTP otherwise.
- **JMAP push**: `_JmapAccountSync._wait()` subscribes to the server's SSE
  `eventSourceUrl` via `watchJmapPush`; falls back to 30 s polling when push
  is unavailable or the server does not advertise the URL.
- `notUpdated`/`notDestroyed` per-item errors from `Email/set` are treated as
  permanent failures and discarded immediately (no retry).

### IMAP

- Background sync starts automatically for IMAP accounts.
- Mailbox lists and mailbox counters are synced into the local database.
- Email headers, flags, and attachment metadata are pulled from IMAP into the local database.
- Email bodies are fetched on demand and cached locally.
- All mailboxes (not just INBOX) are synced each cycle.
- Incremental sync: `(lastUid, uidValidity)` checkpoint stored in `sync_state`; only
  new UIDs are fetched on subsequent runs; UID-validity change triggers a full re-scan.
- Deletion reconciliation: server UID set is compared against local rows; any email
  absent from the server is removed from the local DB.
- Local mutations (flag, move, delete) are written to `pending_changes` with an
  optimistic local update; `flushPendingChanges` drains the queue over a single
  IMAP connection at the start of each sync cycle.
- Sent messages are appended to the Sent folder after SMTP delivery.
- Sync retries use exponential backoff after failures.

### Cross-protocol

- `sync_log` table records each sync cycle's account, result (ok / error), error
  message, start time, and finish time. Used for debugging and "last synced" UI.
- **Conflict-resolution policy: server-wins.** The next sync cycle always
  overwrites local state with server values. Outbound mutations in
  `pending_changes` are retried up to 5 times before being evicted, preventing
  unbounded queue growth. Permanent per-item JMAP errors (`notFound`,
  `forbidden`) are discarded immediately; transient errors (network, 500)
  are retried up to the limit.
- Integration test (`test/integration/concurrent_sync_test.dart`) concurrently
  syncs an IMAP account (alice) and a JMAP account (bob) against a real Stalwart
  server and verifies the Drift DB cache is consistent (no duplicates, correct
  counts, no pending changes).

---

## Next steps

All planned sync-layer features are implemented. Possible future work:

- **IMAP CONDSTORE / QRESYNC**: use `MODSEQ` for faster incremental sync on
  servers that support RFC 7162.
- **JMAP blob expiry**: detect and re-fetch body blobs that the server has
  purged (currently the cache is assumed permanent).
- **Offline compose queue**: surface `pending_changes` failures in the UI so
  the user can retry or discard stuck outbound mutations.