@remit/api-openapi-types 0.0.45 → 0.0.47

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remit/api-openapi-types",
-  "version": "0.0.45",
+  "version": "0.0.47",
   "type": "module",
   "main": "types.d.ts",
   "types": "types.d.ts",

package/types.d.ts

@@ -3463,11 +3463,18 @@ asking "is this slot free" never has to do the merging itself.
       reportedAt: number;
     }
     /**
-     * Aggregate response for `searchThreads`. Carries the matching rows (`items`), a
-pagination `continuationToken`, and an optional `count` of every message the
-query matches. `items` is omitted when `results=false` (count-only); `count` is
-present only when `count=true`. Thread-specific so the shared `ResultList<T>`
-(7 endpoints) stays untouched.
+     * Aggregate response for the filterable thread listings — `searchThreads` and
+`listAllThreads`. Carries the matching rows (`items`), a pagination
+`continuationToken`, and an optional `count` of what the query matches.
+`items` is omitted when `results=false` (count-only); `count` is present only
+when `count=true`. Thread-specific so the shared `ResultList<T>` (7 endpoints)
+stays untouched.
+
+`listAllThreads` answers with this model rather than `ResultList<T>` for that
+same reason: it needs the count field and the shared model cannot carry one.
+One model over both operations rather than a second of the same shape, so a
+client reading a filtered thread listing reads one response type whether the
+listing is scoped to a mailbox or spans every account.
      */
     export interface ThreadSearchResponse {
       /**
@@ -3479,7 +3486,18 @@ present only when `count=true`. Thread-specific so the shared `ResultList<T>`
        */
       continuationToken?: String800;
       /**
-       * How many messages the query matches, over the whole mailbox and independent of `limit`. Present only when `count=true`. With `senderTrust` or `dkimMismatch` in the query the count is over the enriched window instead, since those are resolved off the row.
+       * How much the query matches, over the whole scope and independent of `limit`.
+Present only when `count=true`.
+
+Each operation counts what it lists. `searchThreads` lists messages of one
+mailbox and counts messages; with `senderTrust` or `dkimMismatch` in the
+query that count is over the enriched window instead, since those are
+resolved off the row. `listAllThreads` counts CONVERSATIONS across every
+non-muted mailbox of every account — a thread holding two matching messages
+counts once, and so does one message reachable through a real folder and a
+virtual copy of it — because that is what the cross-account listing renders
+after collapsing by `threadId`. A count that disagreed with the rows beneath
+it would be a third number for the same set.
        */
       count?: number;
     }
@@ -4359,7 +4377,7 @@ either way and cannot tell which it received.
        */
       status: MessageStatus;
       /**
-       * Sync status for move/delete operations. Defaults to `synced` (nothing pending) so a freshly-synced message never looks like it has an outstanding move/delete.
+       * Sync status for move/delete operations. The `synced` column default only applies to a row written without the field: the repository always supplies one, and an ordinary inbound sync writes `pending`, which nothing later promotes. So `pending` here does not mean an outstanding move or delete — `status` names that, and `failed` marks a mutation that gave up.
        */
       syncStatus: MessageSyncStatus;
       /**
@@ -6451,6 +6469,11 @@ declare namespace Paths {
       limit?: number;
       starred?: boolean;
       query?: string;
+      category?: Components.Schemas.MessageCategory[];
+      unread?: boolean;
+      attachments?: boolean;
+      count?: boolean;
+      results?: boolean;
     }
     namespace Responses {
       export type $200 = void;
@@ -7215,6 +7238,10 @@ Search mode and pagination: `limit` is a page size over MATCHES, capped server-s
 What a row is in search mode: one per message, not one per mailbox. This differs from the starred mode above, where the same mail filed in two folders is two rows sharing a `threadId`. Collapsing by `threadId` is still a client's job if it renders one row per CONVERSATION, since distinct messages in one thread remain distinct rows here.
 
 Callers that omit `query` are unaffected: the INBOX (and starred) listings behave exactly as before.
+
+Row filters: `category`, `unread` and `attachments` are columns on the ThreadMessage row, so each is a predicate inside the query rather than a pass over what a page returned. They compose with every mode above — INBOX, starred and search alike — and a page therefore comes back full of matches however rare the criterion is. This is what the cross-account collections need: filtering the pages a client happens to have loaded shows an empty list whenever the matching mail sits below the newest page (#308).
+
+Counting: `count=true` answers how many CONVERSATIONS match, over the whole scope and independent of `limit`. `results=false` omits the rows, which is how a header total is read without also paying for a page of mail. Conversations rather than rows because that is what this listing renders: a row is per mailbox, so the same mail filed in two folders is two rows sharing a `threadId`, and clients collapse by it. Counting rows would put a third number beside a list that shows a second one.
    */
   'listAllThreads'(
     parameters?: Parameters<Paths.ListAllThreads.QueryParameters> | null,
@@ -8037,6 +8064,10 @@ Search mode and pagination: `limit` is a page size over MATCHES, capped server-s
 What a row is in search mode: one per message, not one per mailbox. This differs from the starred mode above, where the same mail filed in two folders is two rows sharing a `threadId`. Collapsing by `threadId` is still a client's job if it renders one row per CONVERSATION, since distinct messages in one thread remain distinct rows here.
 
 Callers that omit `query` are unaffected: the INBOX (and starred) listings behave exactly as before.
+
+Row filters: `category`, `unread` and `attachments` are columns on the ThreadMessage row, so each is a predicate inside the query rather than a pass over what a page returned. They compose with every mode above — INBOX, starred and search alike — and a page therefore comes back full of matches however rare the criterion is. This is what the cross-account collections need: filtering the pages a client happens to have loaded shows an empty list whenever the matching mail sits below the newest page (#308).
+
+Counting: `count=true` answers how many CONVERSATIONS match, over the whole scope and independent of `limit`. `results=false` omits the rows, which is how a header total is read without also paying for a page of mail. Conversations rather than rows because that is what this listing renders: a row is per mailbox, so the same mail filed in two folders is two rows sharing a `threadId`, and clients collapse by it. Counting rows would put a third number beside a list that shows a second one.
      */
     'get'(
       parameters?: Parameters<Paths.ListAllThreads.QueryParameters> | null,