@remit/api-openapi-types 0.0.46 → 0.0.48

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remit/api-openapi-types",
-  "version": "0.0.46",
+  "version": "0.0.48",
   "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,23 @@ 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. Exact: no page size bounds
+it, no cursor narrows it, so it is the same number on the first page and the
+last. Present only when `count=true`.
+
+Each operation counts what it lists. `searchThreads` lists messages of one
+mailbox and counts messages. `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.
+
+Absent when the query carries `senderTrust` or `dkimMismatch`, even with
+`count=true`. Those are resolved by enriching rows rather than by a
+predicate, so no exact count exists short of enriching the whole mailbox.
+Absence says so; a page's post-filter length labelled `count` would be a
+page length presented as a total. A client with no number renders none.
        */
       count?: number;
     }
@@ -6451,6 +6474,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 +7243,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 +8069,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,