@rapidmx/activesync-plugin 1.0.0-beta.2 → 1.0.0-beta.3

package/dist/types/commands/PingCommand.d.ts

@@ -1,33 +1,91 @@
 import { type WbxmlElement } from "../codec/WbxmlElement.js";
 import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/** Binds one MS-ASCMD `Class` value to the entity class whose rows a `Ping` checks for pending changes. */
+export interface PingCollectionBinding {
+    entityClass: any;
+}
 /**
  * Handles EAS `Ping`: a long-poll HTTP request that blocks for up to `HeartbeatInterval` seconds waiting for a
- * change in any of the client-specified folders, then reports which (if any) actually changed. No websocket
- * needed - subscribes a plain, request-scoped Redis client (the same construction `BasePushRoute.connect()`
- * uses, minus its own per-socket bookkeeping this one-shot request doesn't need) directly to the requested
- * `folderUid` channels. Every `Message`/`CalendarEvent`/etc. mutation already publishes to exactly these
- * channels via `BaseScopedChildRoute.notify()`/`RepoUtils`'s own push - `Ping` needs no new publish call site
- * of its own, only a subscriber.
+ * change in any of the client-specified folders, then reports which (if any) actually changed. Every
+ * `Message`/`CalendarEvent`/etc. mutation already publishes to the `folderUid` channels via
+ * `BaseScopedChildRoute.notify()`/`RepoUtils`'s own push - `Ping` only needs a subscriber.
+ *
+ * Resource bounds:
+ * - One shared Redis subscriber client per process (per Redis URL), lazily connected once. Each `Ping` attaches
+ * its own listener to its channels and removes exactly that listener when it settles. A connect/subscribe
+ * failure fails open (the `Ping` just waits out its heartbeat and reports no changes) and a failed connect is
+ * forgotten so a later `Ping` retries it.
+ * - At most one active `Ping` per (mailbox, device) per process: a newer one supersedes (answers Status 1) the
+ * older one.
+ * - The wait ends as soon as the HTTP response finishes (including a client abort).
+ * - More than `mail:eas:ping_max_folders` folders is rejected with Status 6 before any ACL work, and the ACL
+ * checks themselves run in bounded concurrent chunks.
+ * - Without a `datastores:events` config the `Ping` still waits the full (clamped) heartbeat before answering
+ * Status 1, so a device can't hot-loop against it.
+ *
+ * **Changes made before the `Ping` started**: a publish only reaches a subscriber that exists at that moment, so a
+ * change landing between the device's last `Sync` and this `Ping`'s subscribe would otherwise go unnoticed until
+ * the next change. Once subscribed (or right away, without Redis), each folder's stream is checked for a row after
+ * the cursor its `EasCollectionState` recorded, and any folder with one is answered with Status 2 immediately. This
+ * needs `collectionStateClass`/`collectionBindings` (set by `PingCommandMongo`/`PingCommandSQL`); a folder the
+ * device never synced has no cursor and isn't checked.
  *
  * Requested folder uids are filtered down to only those the caller currently has `READ` on before subscribing -
- * matching every other command's ownership check on a client-supplied id, since without it a device could
- * long-poll indefinitely on any folder uid it happens to know (including one it used to have legitimate access
- * to and no longer does) and learn purely from this channel when that other mailbox's data changes.
+ * without it a device could long-poll on any folder uid it happens to know (including one whose share was since
+ * revoked) and learn from this channel when that other mailbox's data changes.
  *
  * @author Jean-Philippe Steinmetz
  */
 export declare class PingCommand implements EasCommandHandler {
+    /** Shared subscriber connections, keyed by Redis URL - each value resolves once that client is connected. */
+    private static readonly subscribers;
+    /** The cancel function of the currently active `Ping` for each (mailbox, device) pair. */
+    private static readonly activePings;
     readonly command = "Ping";
     private redisConfig;
     private minHeartbeatSeconds;
     private maxHeartbeatSeconds;
+    private maxFolders;
     private aclUtils?;
+    /** Supplied by the Mongo/SQL subclasses; without them the pending-change check is skipped. */
+    protected collectionStateClass?: any;
+    protected collectionBindings: Record<string, PingCollectionBinding>;
+    private _objectFactory?;
+    private collectionStateRepo?;
+    private repos;
+    init(): Promise<void>;
+    /** Forgets all process-wide shared state (subscriber clients and active pings). Intended for tests. */
+    static resetSharedState(): void;
     handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
     private statusResponse;
-    /** Subscribes to `folderUids` and resolves with whichever of them published a change first, or `[]` if
-     * `timeoutSeconds` elapses with no publish. A missing `datastores:events` config (Redis pub/sub not set up
-     * for this deployment) fails open to "no changes" rather than blocking forever or throwing - `Ping` is a
-     * best-effort low-latency notification path, not the only way a client ever discovers new mail (it will
-     * eventually poll a real `Sync`/`FolderSync` regardless). */
+    /** Returns the subset of `folderUids` the caller has `READ` on, checking at most `ACL_CHECK_CHUNK_SIZE` at once. */
+    private filterPermitted;
+    /**
+     * The subset of `folderUids` whose change stream has a row the device hasn't synced yet (after its collection's
+     * recorded cursor, other than the device's own writes). A failed lookup counts as "no pending change".
+     *
+     * Batched, so a `Ping` watching hundreds of folders costs a handful of queries rather than three per folder: every
+     * folder's `EasCollectionState` is read in one `in(...)` query per `STATE_LOOKUP_CHUNK`, and each collection class's
+     * folders are checked together (`pendingInClass()`); only a folder that batch can't decide is scanned on its own.
+     */
+    private pendingChanges;
+    /** Every requested folder's collection state for this device, keyed by folder uid - one query per chunk of plain
+     * folder uids (exact-matched in memory), and one query per folder uid that can't be listed in `in(...)`. */
+    private loadStates;
+    /**
+     * The folders among `states` (all of one collection class, stored in `repo`) with a pending change. One pair of
+     * queries (live and soft-deleted rows) reads, across all of them, the rows at or after the earliest cursor, in
+     * stream order, up to `PENDING_BATCH_ROW_LIMIT`. When neither page is full, that is every row that could be pending
+     * for any of the folders, so each folder is decided exactly in memory - the same rule as a per-folder `scanAfter()`.
+     * When a page is full, a folder with a pending row among the rows read is still pending; any other folder is scanned
+     * on its own, as before. A folder uid that can't be listed in `in(...)` is always scanned on its own.
+     */
+    private pendingInClass;
+    /** Returns the process-wide subscriber client for `url`, connecting it on first use. A failed connect is
+     * evicted from the cache (and the client destroyed) so a later call retries. */
+    private static getSubscriber;
+    /** Waits up to `timeoutSeconds` for a publish on any of `folderUids`, resolving with the channel that changed,
+     * or `[]` on timeout, supersede by a newer `Ping` from the same device, request close, or Redis being
+     * unavailable (in which case the full heartbeat is still waited). */
     private waitForChange;
 }

package/dist/types/commands/ProvisionCommand.d.ts

@@ -15,19 +15,25 @@ import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.
  * no way for the server to inspect device state directly either).
  *
  * - **Request 1** (no `PolicyKey` in the body): mint a new policy key, store it on `DeviceSyncState` (not yet
- * provisioned), and send back the policy document under that key. If a `RemoteWipe` was requested for this
- * device (`DeviceSyncState.remoteWipeRequested`, set by an admin - see the remote-wipe route), skip normal
- * policy issuance entirely and send the `RemoteWipe` directive instead.
+ * provisioned), and send back the policy document under that key.
  * - **Request 2** (client echoes the `PolicyKey` back, acknowledging the policy): if the key matches what was
  * minted in request 1 *and* the client's own `Status` is `1`, mark the device provisioned and re-confirm the
  * same key; anything else (a stale/replayed key, a device that never actually saw request 1's response, or a
  * device reporting it could not comply) is rejected without provisioning.
+ * - **While a wipe is pending**, every other Provision request (a policy request *or* an acknowledgement of an
+ * older key) gets the `RemoteWipe` directive and never provisions. Requesting the wipe also clears the stored
+ * policy key (`BaseDeviceSyncStateRoute.remoteWipe`), and `BaseEasRoute` refuses any command whose presented
+ * `X-MS-PolicyKey` doesn't match the stored key, so a device can't keep syncing on its old key.
  * - **RemoteWipe acknowledgement**: after wiping itself, a device sends a bare `<Provision><RemoteWipe>
  * <Status>1</Status></RemoteWipe></Provision>` (no `Policies`). Detected first, ahead of the normal
- * issue/acknowledge branching. Clears `remoteWipeRequested` and stamps `remoteWipeAcknowledgedAt` for audit,
- * but deliberately leaves `provisioned` untouched (`false`, from when the wipe was requested) - the device
- * must complete a genuine fresh Provision handshake to re-add the account, it does not fall straight back into
- * "provisioned". `remoteWipeAccountOnly` is recorded for admin audit only; the wire directive sent to the
+ * issue/acknowledge branching, and ignored (Status 2) unless a wipe is actually pending. Clears `remoteWipeRequested`,
+ * stamps `remoteWipeAcknowledgedAt` for audit and sets `blocked`, leaving `provisioned` `false`.
+ * - **A blocked device** (one that acknowledged a wipe) is refused every Provision request with Status 129
+ * (DeviceIsBlockedForThisUser) - and `BaseEasRoute` refuses its other commands - until an administrator clears the
+ * flag (`BaseDeviceSyncStateRoute.unblock`). Otherwise a device (or whoever holds it) could acknowledge the wipe
+ * without wiping anything and simply provision again. The block (like the wipe itself) is keyed on the client-supplied
+ * `DeviceId`: a client that ignores the directive can pair again under another `DeviceId` with the same credentials -
+ * see `DeviceSyncState.blocked`; revoking the account's credentials is what stops that. `remoteWipeAccountOnly` is recorded for admin audit only; the wire directive sent to the
  * device is identical either way (a real "wipe just this account's data" vs. "wipe the whole device"
  * distinction would require an MDM-capable client extension this library doesn't implement).
  *
@@ -41,14 +47,13 @@ export declare class ProvisionCommand implements EasCommandHandler {
     private requireDeviceEncryption;
     private allowSimplePassword;
     handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
-    /** Request 1: mint and store a new policy key, send the policy document - or, if a remote wipe is
-     * pending for this device, the `RemoteWipe` directive instead. */
+    /** Request 1: mint and store a new policy key and send the policy document. */
     private issuePolicy;
     /** Request 2: the client acknowledges the policy key it was handed in request 1, self-reporting whether
      * it actually applied the policy via its own `Status`. */
     private acknowledgePolicy;
-    /** The device has wiped itself and is acknowledging - clear the pending flag but leave `provisioned`
-     * alone (still `false`, from when the wipe was requested) so a genuine re-provision is required. */
+    /** The device has wiped itself and is acknowledging - clear the pending flag and block the device until an
+     * administrator unblocks it; `provisioned` stays `false` (from when the wipe was requested). */
     private acknowledgeRemoteWipe;
     private persist;
 }

package/dist/types/commands/ResolveRecipientsCommand.d.ts

@@ -1,5 +1,7 @@
 import { type WbxmlElement } from "../codec/WbxmlElement.js";
 import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/** [MS-ASCMD]: a `ResolveRecipients` request MUST NOT contain more than 100 `To` elements. */
+export declare const MAX_RESOLVE_RECIPIENTS_TO = 100;
 /**
  * Handles EAS `ResolveRecipients`: resolves each `<To>` value (a display name, partial name, or address) the
  * client is unsure how to reach against the mailbox's own `Contact` (GAL) store - the same substring-match
@@ -28,8 +30,10 @@ export declare abstract class ResolveRecipientsCommand implements EasCommandHand
     private maxMatches;
     private _objectFactory?;
     private contactRepo?;
+    private logger;
     init(): Promise<void>;
     handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private statusOnly;
     private resolveOne;
     private recipientElement;
     private responseElement;

package/dist/types/commands/SearchCommand.d.ts

@@ -30,7 +30,12 @@ import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.
  * request's own capped fetch actually returned" - a client requesting a `Range` past that cap sees fewer
  * results than may really exist, a documented approximation rather than exact server-side paging.
  *
- * `contactClass`/`messageClass`/`emailAdapterClass` are supplied by the Mongo/SQL concrete subclasses.
+ * **Audit**: the index is the caller's own mailbox's, but a hit is rendered from the stored message, wherever it is
+ * filed now. Results from a mailbox the caller doesn't own (restapi's `isNonOwnerAccess()`) are recorded as one
+ * `MESSAGE_CONTENT_ACCESSED` entry per such mailbox per request, listing the returned message uids (`EasAuditLog`).
+ *
+ * `contactClass`/`messageClass`/`emailAdapterClass`/`mailboxClass`/`auditLogClass` are supplied by the Mongo/SQL
+ * concrete subclasses.
  *
  * @author Jean-Philippe Steinmetz
  */
@@ -39,7 +44,12 @@ export declare abstract class SearchCommand implements EasCommandHandler {
     protected abstract contactClass: any;
     protected abstract messageClass: any;
     protected abstract emailAdapterClass: any;
+    protected abstract mailboxClass: any;
+    protected abstract auditLogClass: any;
     private _objectFactory?;
+    private config?;
+    private logger;
+    private mailboxRepo?;
     private contactRepo?;
     private messageRepo?;
     private emailAdapter?;
@@ -51,6 +61,8 @@ export declare abstract class SearchCommand implements EasCommandHandler {
     handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
     private handleGal;
     private handleMailbox;
+    /** One `MESSAGE_CONTENT_ACCESSED` entry per non-owner mailbox among `page`'s messages (see this class's doc comment). */
+    private auditResults;
     private contactToResult;
     /** Reuses `EmailSyncAdapter.toApplicationData()`'s own field mapping (Subject/From/To/Cc/Bcc/DateReceived/
      * Importance/Read/Flag/Body/ConversationId) for a Mailbox-store search hit's `Properties` - the same

package/dist/types/commands/SyncCommand.d.ts

@@ -1,100 +1,140 @@
 import { type RecoverableBaseEntity } from "@rapidrest/service-core";
 import { type WbxmlElement } from "../codec/WbxmlElement.js";
 import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/** Most `<Collection>`s one `Sync` request may carry - more is answered with a top-level Status 4. */
+export declare const MAX_SYNC_COLLECTIONS = 300;
+/** Most client `Add`/`Change`/`Delete` commands one collection of a `Sync` request may carry - more is answered
+ * with that collection's Status 4, without applying any of them. */
+export declare const MAX_SYNC_COMMANDS_PER_COLLECTION = 512;
 /** Binds one MS-ASCMD `Class` value (`"Email"`, `"Contacts"`, ...) to the concrete entity class `SyncCommand`
  * should build a `RepoUtils` for, and the adapter class that maps that entity to/from `ApplicationData`.
- * Supplied by the Mongo/SQL concrete subclasses, one map entry per supported collection type.
- *
- * `adapterClass`, not a pre-built `adapter` instance: `SyncCommand.init()` instantiates each one itself via
- * `ObjectFactory`, so an adapter can `@Inject` its own dependencies (`EmailSyncAdapter` needs `BlobStore` for a
- * Draft's body) exactly like any other DI-managed class in this library - a bare `new EmailSyncAdapter()` has
- * no way to satisfy that. */
+ * Supplied by the Mongo/SQL concrete subclasses, one map entry per supported collection type. */
 export interface SyncCollectionBinding<T extends RecoverableBaseEntity> {
     entityClass: any;
     adapterClass: any;
 }
 /**
- * Handles EAS `Sync`: enumerates `Add`/`Change`/`Delete`s for a single folder's contents since the device's last
- * `Sync` of that folder, using the same watermark-based cursor mechanism `FolderSyncCommand` uses (via
- * `EasSyncKeyUtils`), scoped by `folderUid` instead of `mailboxUid`, and keyed per-folder in
- * `DeviceSyncState.folderSyncKeys` (the `CollectionId` a client sends *is* the `folderUid` - this library never
- * invents a separate collection identifier).
+ * Handles EAS `Sync` for `Email`/`Contacts`/`Calendar`/`Tasks` folders.
+ *
+ * **Per-collection state** lives in its own `EasCollectionState` row per (mailbox, device, folder) - see that
+ * model - rather than in `DeviceSyncState`, so concurrent `Sync`s of different folders never contend for one row.
+ * Besides the issued `SyncKey`, the row records exactly which items the device holds (inline in `serverIds` while
+ * small, in `EasCollectionChunk` rows once large - see `EasCollectionStore`). That is what makes the reported
+ * commands correct rather than guessed: an item the device doesn't hold is always an `Add` (including on the first
+ * round after `SyncKey 0`), an item it holds is a `Change`, and an item it holds that has been deleted *or moved to
+ * another folder* is a `Delete` - see `EasCollectionSync.enumerateCollection`.
+ *
+ * **One round per collection at a time**: each collection's round runs under a lease on (mailbox, device, folder)
+ * (`EasCollectionLease`: in-process, plus Redis `datastores:cache` across server copies when configured), and its
+ * state is read only once the lease is held - a second `Sync` of the same collection waits for the first to finish
+ * and then sees its result (typically answering the now-previous `SyncKey` as a retry), instead of both computing a
+ * round from the same state. A lease not acquired within `LEASE_WAIT_MS` is answered with Status 16 (retry).
+ *
+ * **Round order**: the client's own `Commands` are applied first, then server changes are enumerated. The device's
+ * own writes are not echoed back: each successful `Add`/`Change` records the resulting `dateModified` in the row's
+ * `echoes`, and a changed row still carrying exactly that timestamp is skipped. The cursor itself only ever advances
+ * past rows actually enumerated, never past a pending server change.
+ *
+ * **Lost state**: a round's state that can't be saved is answered with the collection's Status 3 (and a failed
+ * `SyncKey 0` restart with Status 5), never with a `SyncKey` the server doesn't have - the device re-syncs from
+ * scratch instead of continuing from a key whose held set was never recorded.
+ *
+ * **Retries**: a client that never received a response re-sends the `SyncKey` it still holds. The row keeps the
+ * previous round's key and delta (`previous`), so that key is accepted and the round is recomputed from the state
+ * before it; an `Add` re-sent with the same `ClientId` is answered with the item created the first time, and a
+ * `Delete` of an item that round already removed succeeds silently.
+ *
+ * **Options honoured**: `WindowSize` (capped by `mail:eas:sync_window_size` and 512), `FilterType` (age window for
+ * `Email`/`Calendar`, incomplete-only for `Tasks`; applied to items the device doesn't hold yet). A collection
+ * started without `Options` has no filter recorded, and the first `FilterType` sent while the device still holds
+ * nothing is adopted (clients commonly send `Options` only from the second request on); a `FilterType` differing
+ * from the recorded one otherwise gets Status 3 so the client re-syncs from 0. `DeletesAsMoves` (default `true`: an
+ * `Email` delete moves the message to Deleted Items; a delete inside Deleted Items, or with `DeletesAsMoves` `0`,
+ * deletes it) and `GetChanges` `0` (no server changes this round).
  *
- * **Multi-collection requests**: every `<Collection>` in a request's `<Collections>` is processed and gets its
- * own `<Collection>` entry in the response, each with its own independent `SyncKey`/`Status` - a client
- * syncing several folders in one round trip (the common case once the initial per-folder backlog is done)
- * gets one response covering all of them. All per-collection `SyncKey`/remembered-`Class` writes for the whole
- * request are batched into a single `persistDeviceSyncState` call after every collection has been processed
- * (never one call per collection) - see `EasSyncKeyUtils.persistDeviceSyncState`'s own doc comment for why a
- * second write to the same `DeviceSyncState` within one request must never be built off a stale copy.
+ * **Meetings**: a device deleting or editing an attendee's copy of someone else's meeting never makes restapi's
+ * `MeetingSchedulingJob` send cancellations/invitations as the organizer - see `CalendarSyncAdapter.beforeDelete`
+ * and its `fromApplicationData`.
  *
- * **`Class` is only required on a collection's first (`SyncKey "0"`) request**, per `[MS-ASCMD]` - once seen,
- * it's remembered in `DeviceSyncState.folderCollectionClasses` (keyed by `folderUid`) so a later request may
- * omit it; omitting it for a folder never previously synced still gets `Status 4` (nothing to fall back to).
+ * **Access**: every `CollectionId` needs `READ` on the folder (otherwise Status 4, indistinguishable from an unknown
+ * collection); `Add`/`Change`/`Delete` additionally need `CREATE`/`UPDATE`/`DELETE`, and a `ServerId` that resolves
+ * to an item outside the synced folder is reported as not found (Status 8). An `Email` `Add` is only accepted in
+ * a Drafts folder ([MS-ASCMD]: no non-draft email may be added by a client), and a new item's `mailboxUid` is the
+ * folder's own mailbox, so an item added to a shared folder belongs to that folder's mailbox. An `Email` body can only
+ * be changed on a genuine draft (`EmailSyncAdapter`), and a delete-as-move out of Outbox cancels the scheduled send
+ * (`MessageMoveRules.planMessageMove`; Status 6 once the message was relayed), and no delete at all happens while a send of
+ * the message is in flight (`hasLiveSendLease`, Status 6). Every update is version-checked on both
+ * backends (`asEntity`).
  *
- * **Every `CollectionId` is ACL-checked against the caller before it's touched**: `processCollection()` requires
- * `ACLAction.READ` on the folder before enumerating or accepting any Commands for it at all (a folder the caller
- * can't read is reported the same as an unrecognized collection - Status `4` - rather than leaking whether it
- * exists); `applyAdd`/`applyChange`/`applyDelete` additionally require `CREATE`/`UPDATE`/`DELETE` respectively,
- * and `applyChange`/`applyDelete` re-verify the resolved item's own `folderUid` actually matches the collection
- * being synced (treating a mismatch identically to "not found" - Status `8` - never revealing that the
- * `ServerId` resolves to something real elsewhere). Without this, a client could supply any other mailbox's
- * folder/item uid as its own `CollectionId`/`ServerId` and read or mutate that mailbox's data directly - the
- * same ownership-verification-after-an-`ignoreACL`-lookup pattern `ItemOperationsCommand`/`MoveItemsCommand`
- * already use, applied consistently here too.
+ * **Audit** (`EasAuditLog`), only in a mailbox the caller doesn't own (restapi's `isNonOwnerAccess()` - an administrator
+ * or a delegate syncing a shared folder), and only for `Email`: a round that sends `Add`/`Change` items records one
+ * `MESSAGE_CONTENT_ACCESSED` entry for the collection listing the sent message uids (at most a window's worth), rather
+ * than one per row; each successful client `Delete` records one `MESSAGE_DELETE` entry, as restapi's REST delete does.
  *
- * **Pragmatic subset, deliberately not the full MS-ASCMD `Sync` surface**:
- * - **Client-originated `Add`/`Change`/`Delete` commands are accepted for every collection type**, including
- * `Email` (a device creating/editing a Draft, or deleting a message locally - see `applyAdd`/`applyChange`/
- * `applyDelete`). `[MS-ASCMD]` itself disallows `Add`/`Change` for any *non-draft* `Email` item - this library
- * doesn't verify a Sync `Email` Add/Change actually targets the caller's own Drafts folder *specifically*
- * (only that it's a folder the caller actually owns/can write to - see above), matching how Contacts/Calendar/
- * Tasks folder targeting is equally unchecked beyond ownership elsewhere. A collection whose adapter has no
- * `fromApplicationData` at all would get Status `6` for `Add`/`Change` instead, but every adapter today
- * implements it. Per `[MS-ASCMD]`'s own "Add (Sync)"/"Status (Sync)" pages: `Add` always gets a `Responses`
- * entry (it must report the assigned `ServerId`); `Change`/`Delete` only get one on **failure** - a silent
- * success means "assume it worked."
- * - Only a body preview is returned per item (see `EmailSyncAdapter`'s own doc comment) - full body content is
- * fetched separately via `ItemOperationsCommand`. A Draft's `Email` Add/Change is plain-text-only, with no
- * attachment support (mirrors `ComposeMailCommand`'s own already-documented attachment gap).
+ * Per `[MS-ASCMD]`, `Add` always gets a `Responses` entry; `Change`/`Delete` only on failure.
  *
  * @author Jean-Philippe Steinmetz
  */
 export declare abstract class SyncCommand implements EasCommandHandler {
     readonly command = "Sync";
     protected abstract collectionBindings: Record<string, SyncCollectionBinding<any>>;
-    /** Supplied by the Mongo/SQL concrete subclasses so a client-originated `Add`'s `newEntityDefaults()` can
-     * be given the caller's own `Mailbox` (`EmailSyncAdapter` needs it for a new Draft's `from`) - same
-     * one-line-per-backend pattern `MeetingResponseCommand`/`SettingsCommand` already use. */
+    /** Supplied by the Mongo/SQL concrete subclasses. */
     protected abstract mailboxClass: any;
+    protected abstract folderClass: any;
+    protected abstract collectionStateClass: any;
+    protected abstract collectionChunkClass: any;
+    protected abstract auditLogClass: any;
     private windowSize;
+    private cacheConfig;
+    private config?;
+    protected moveScanLimit: number;
+    protected reconcileLimit: number;
+    protected leaseWaitMs: number;
     private _objectFactory?;
     private aclUtils?;
+    private logger;
     private repos;
     private adapters;
     private mailboxRepo?;
+    private folderRepo?;
+    private collectionStateRepo?;
+    private collectionChunkRepo?;
     init(): Promise<void>;
-    /** Resolves the caller's own `Mailbox` at most once per request, and only if actually needed - most `Sync`
-     * requests contain no client-originated `Add` at all, so most requests never pay this extra round trip. */
+    private get chunkStore();
+    /** Resolves a mailbox at most once per request, and only if actually needed. */
     private mailboxLoader;
     handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
-    /** Processes one `<Collection>` from the request into its own `<Collection>` response element, plus (when
-     * this round advanced anything) the `folderUid`/new `SyncKey`/remembered `Class` for `handle()` to fold
-     * into its single end-of-request `persistDeviceSyncState` call - this method itself never persists
-     * anything, so it's safe to call once per collection in a request without the write-batching hazard
-     * `EasSyncKeyUtils.persistDeviceSyncState`'s doc comment describes. */
+    private effectiveWindowSize;
     private processCollection;
-    private itemToCommandElement;
-    /** One client-originated command's outcome: `response` is a `Responses/{Add,Change,Delete}` entry to
-     * include (per MS-ASCMD, always present for `Add`, only present on failure for `Change`/`Delete`);
-     * `writtenAt` is the resulting `dateModified` of whatever was actually written, used to advance the
-     * persisted watermark past this round's own writes (see `handle()`'s own comment on why). */
+    /** The rest of `processCollection`, run while holding the collection's lease. */
+    private processLocked;
+    /** `SyncKey 0`: (re)starts the collection with an empty item set. Per [MS-ASCMD] the response carries only the
+     * new key; the next round reports every item as an `Add`. */
+    private startCollection;
+    /**
+     * Writes the held set (`held.ids`, given the set `held.loaded` the round started from) and then creates or
+     * updates the collection's state row. Returns `false` - after logging - when anything failed (including losing a
+     * race for the row): the caller must then not hand out the new key. A `"restart"` empties the held set.
+     *
+     * **Chunk writes can't be atomic with the state row**, so before any chunk row is touched the state row is first
+     * marked `chunked` with both its `SyncKey` and its previous round's key blanked (`invalidateBeforeChunkWrite()`).
+     * If anything after that fails - including the final state write, and even when the device never sees this round's
+     * Status 3 - no key matches the half-written chunks any more: the device's next `Sync` gets Status 3 and restarts
+     * with `SyncKey 0`, which always removes every chunk row of the collection (whether or not the row says `chunked`,
+     * so rows orphaned before this rule existed are cleared too). A collection converting from inline to chunked also
+     * clears leftover chunk rows first, so an orphan can never collide with the unique `chunkIndex`.
+     */
+    private saveState;
+    /** Marks `stored` chunked with no acceptable `SyncKey` (current or previous) before its chunk rows are written - see
+     * `saveState()`. Returns the updated row, whose version the final state write must carry. */
+    private invalidateBeforeChunkWrite;
     private addResponseElement;
     private statusResponseElement;
+    /** Remembers the `dateModified` the device's own write left on `item`, so the write isn't echoed back. */
+    private noteWrite;
     private applyAdd;
     private applyChange;
     private applyDelete;
-    /** Builds one `<Collection>` response element - `handle()` collects one of these per request `<Collection>`
-     * and wraps the whole set in a single `<Sync><Collections>`. */
+    /** Builds one `<Collection>` response element. */
     private collectionResponse;
 }

package/dist/types/commands/mongo/GetItemEstimateCommandMongo.d.ts

@@ -3,5 +3,8 @@ import { GetItemEstimateCommand, type EstimateCollectionBinding } from "../GetIt
  * @author Jean-Philippe Steinmetz
  */
 export declare class GetItemEstimateCommandMongo extends GetItemEstimateCommand {
+    protected folderClass: any;
+    protected collectionStateClass: any;
+    protected collectionChunkClass: any;
     protected collectionBindings: Record<string, EstimateCollectionBinding>;
 }

package/dist/types/commands/mongo/ItemOperationsCommandMongo.d.ts

@@ -6,4 +6,6 @@ export declare class ItemOperationsCommandMongo extends ItemOperationsCommand {
     protected folderClass: any;
     protected messageClass: any;
     protected attachmentClass: any;
+    protected mailboxClass: any;
+    protected auditLogClass: any;
 }

package/dist/types/commands/mongo/MeetingResponseCommandMongo.d.ts

@@ -5,4 +5,5 @@ import { MeetingResponseCommand } from "../MeetingResponseCommand.js";
 export declare class MeetingResponseCommandMongo extends MeetingResponseCommand {
     protected calendarEventClass: any;
     protected mailboxClass: any;
+    protected messageClass: any;
 }

package/dist/types/commands/mongo/PingCommandMongo.d.ts

@@ -0,0 +1,8 @@
+import { PingCommand, type PingCollectionBinding } from "../PingCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class PingCommandMongo extends PingCommand {
+    protected collectionStateClass: any;
+    protected collectionBindings: Record<string, PingCollectionBinding>;
+}

package/dist/types/commands/mongo/SearchCommandMongo.d.ts

@@ -6,4 +6,6 @@ export declare class SearchCommandMongo extends SearchCommand {
     protected contactClass: any;
     protected messageClass: any;
     protected emailAdapterClass: any;
+    protected mailboxClass: any;
+    protected auditLogClass: any;
 }

package/dist/types/commands/mongo/SendMailCommandMongo.d.ts

@@ -5,4 +5,5 @@ import { SendMailCommand } from "../SendMailCommand.js";
 export declare class SendMailCommandMongo extends SendMailCommand {
     protected folderClass: any;
     protected messageClass: any;
+    protected mailboxClass: any;
 }

package/dist/types/commands/mongo/SmartForwardCommandMongo.d.ts

@@ -5,4 +5,5 @@ import { SmartForwardCommand } from "../SmartForwardCommand.js";
 export declare class SmartForwardCommandMongo extends SmartForwardCommand {
     protected folderClass: any;
     protected messageClass: any;
+    protected mailboxClass: any;
 }

package/dist/types/commands/mongo/SmartReplyCommandMongo.d.ts

@@ -5,4 +5,5 @@ import { SmartReplyCommand } from "../SmartReplyCommand.js";
 export declare class SmartReplyCommandMongo extends SmartReplyCommand {
     protected folderClass: any;
     protected messageClass: any;
+    protected mailboxClass: any;
 }

package/dist/types/commands/mongo/SyncCommandMongo.d.ts

@@ -4,5 +4,9 @@ import { SyncCommand, type SyncCollectionBinding } from "../SyncCommand.js";
  */
 export declare class SyncCommandMongo extends SyncCommand {
     protected mailboxClass: any;
+    protected auditLogClass: any;
+    protected folderClass: any;
+    protected collectionStateClass: any;
+    protected collectionChunkClass: any;
     protected collectionBindings: Record<string, SyncCollectionBinding<any>>;
 }

package/dist/types/commands/mongo/index.d.ts

@@ -7,3 +7,4 @@ export * from "./ItemOperationsCommandMongo.js";
 export * from "./SearchCommandMongo.js";
 export * from "./MeetingResponseCommandMongo.js";
 export * from "./SettingsCommandMongo.js";
+export * from "./PingCommandMongo.js";

package/dist/types/commands/sql/GetItemEstimateCommandSQL.d.ts

@@ -3,5 +3,8 @@ import { GetItemEstimateCommand, type EstimateCollectionBinding } from "../GetIt
  * @author Jean-Philippe Steinmetz
  */
 export declare class GetItemEstimateCommandSQL extends GetItemEstimateCommand {
+    protected folderClass: any;
+    protected collectionStateClass: any;
+    protected collectionChunkClass: any;
     protected collectionBindings: Record<string, EstimateCollectionBinding>;
 }

package/dist/types/commands/sql/ItemOperationsCommandSQL.d.ts

@@ -6,4 +6,6 @@ export declare class ItemOperationsCommandSQL extends ItemOperationsCommand {
     protected folderClass: any;
     protected messageClass: any;
     protected attachmentClass: any;
+    protected mailboxClass: any;
+    protected auditLogClass: any;
 }

package/dist/types/commands/sql/MeetingResponseCommandSQL.d.ts

@@ -5,4 +5,5 @@ import { MeetingResponseCommand } from "../MeetingResponseCommand.js";
 export declare class MeetingResponseCommandSQL extends MeetingResponseCommand {
     protected calendarEventClass: any;
     protected mailboxClass: any;
+    protected messageClass: any;
 }

package/dist/types/commands/sql/PingCommandSQL.d.ts

@@ -0,0 +1,8 @@
+import { PingCommand, type PingCollectionBinding } from "../PingCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class PingCommandSQL extends PingCommand {
+    protected collectionStateClass: any;
+    protected collectionBindings: Record<string, PingCollectionBinding>;
+}

package/dist/types/commands/sql/SearchCommandSQL.d.ts

@@ -6,4 +6,6 @@ export declare class SearchCommandSQL extends SearchCommand {
     protected contactClass: any;
     protected messageClass: any;
     protected emailAdapterClass: any;
+    protected mailboxClass: any;
+    protected auditLogClass: any;
 }

package/dist/types/commands/sql/SendMailCommandSQL.d.ts

@@ -5,4 +5,5 @@ import { SendMailCommand } from "../SendMailCommand.js";
 export declare class SendMailCommandSQL extends SendMailCommand {
     protected folderClass: any;
     protected messageClass: any;
+    protected mailboxClass: any;
 }

package/dist/types/commands/sql/SmartForwardCommandSQL.d.ts

@@ -5,4 +5,5 @@ import { SmartForwardCommand } from "../SmartForwardCommand.js";
 export declare class SmartForwardCommandSQL extends SmartForwardCommand {
     protected folderClass: any;
     protected messageClass: any;
+    protected mailboxClass: any;
 }

package/dist/types/commands/sql/SmartReplyCommandSQL.d.ts

@@ -5,4 +5,5 @@ import { SmartReplyCommand } from "../SmartReplyCommand.js";
 export declare class SmartReplyCommandSQL extends SmartReplyCommand {
     protected folderClass: any;
     protected messageClass: any;
+    protected mailboxClass: any;
 }

package/dist/types/commands/sql/SyncCommandSQL.d.ts

@@ -4,5 +4,9 @@ import { SyncCommand, type SyncCollectionBinding } from "../SyncCommand.js";
  */
 export declare class SyncCommandSQL extends SyncCommand {
     protected mailboxClass: any;
+    protected auditLogClass: any;
+    protected folderClass: any;
+    protected collectionStateClass: any;
+    protected collectionChunkClass: any;
     protected collectionBindings: Record<string, SyncCollectionBinding<any>>;
 }

package/dist/types/commands/sql/index.d.ts

@@ -7,3 +7,4 @@ export * from "./ItemOperationsCommandSQL.js";
 export * from "./SearchCommandSQL.js";
 export * from "./MeetingResponseCommandSQL.js";
 export * from "./SettingsCommandSQL.js";
+export * from "./PingCommandSQL.js";

package/dist/types/index.d.ts

@@ -30,9 +30,14 @@ export * from "./codec/WbxmlDecoder.js";
 export * from "./BaseEasRoute.js";
 export * from "./BaseDeviceSyncStateRoute.js";
 export * from "./models/DeviceSyncState.js";
+export * from "./models/EasCollectionState.js";
+export * from "./models/EasCollectionChunk.js";
 export * from "./jobs/EasDeviceStateCleanupJob.js";
 export * from "./EasCommandHandler.js";
 export * from "./EasSyncKeyUtils.js";
+export * from "./EasCollectionSync.js";
+export * from "./EasCollectionStore.js";
+export * from "./EasCollectionLease.js";
 export * from "./CompactDateTime.js";
 export * from "./commands/ProvisionCommand.js";
 export * from "./commands/FolderSyncCommand.js";