@remit/api-openapi-types 0.0.55 → 0.0.57

package/package.json

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

package/types.d.ts

@@ -1648,17 +1648,17 @@ with `onExisting: merge` to upsert instead.
        */
       parentMailboxId: string;
       /**
-       * Sync status for mailbox operations (create, rename, delete)
+       * Which folder mutation is outstanding, read as a pair with `pendingPath` (docs/architecture/folder-rename-and-delete.md D1, D3). Total: a row written without one is `synced`, because a folder the server just told us about is confirmed. Four values carry six states — `pending` covers a create and a rename in flight, `failed` covers a failed rename and a failed delete — so every guard and every transition predicate names the pair, never this field alone.
        */
-      syncStatus?: MailboxSyncStatus;
+      syncStatus: MailboxSyncStatus;
       /**
-       * Cursor integrity state machine for stored UIDs (epic #1281 invariant 5, issue #1272). Total per RFC 032: defaults to `normal` rather than being absent. A row written before this field existed reads back as `normal` (unset DynamoDB/Postgres attribute deserializes to the schema default).
+       * The path a recorded rename is moving this folder to. Absent unless a rename is in flight or has just failed, which is what tells a create in flight from a rename in flight (D2, D3). `fullPath` stays the path the server holds throughout, so a failed rename is this field cleared rather than a subtree of paths restored. Invariant: non-null only while `syncStatus` is `pending` or `failed`.
        */
-      cursorState: MailboxCursorState;
+      pendingPath?: String512;
       /**
-       * Previous path before rename (used during RENAME sync)
+       * Cursor integrity state machine for stored UIDs (epic #1281 invariant 5, issue #1272). Total per RFC 032: defaults to `normal` rather than being absent. A row written before this field existed reads back as `normal` (unset DynamoDB/Postgres attribute deserializes to the schema default).
        */
-      oldPath?: String512;
+      cursorState: MailboxCursorState;
       /**
        * Denormalized list of IMAP SPECIAL-USE designations (RFC 6154). Populated from the same `\Sent`, `\Drafts`, etc. attributes the server reports during LIST. Stored on the row to avoid an N+1 join when listing mailboxes.
        */
@@ -1719,9 +1719,13 @@ with `onExisting: merge` to upsert instead.
        */
       lastMessageSyncAt: number;
       /**
-       * Sync status for mailbox operations (create, rename, delete)
+       * Which folder mutation is outstanding, read as a pair with `pendingPath` (docs/architecture/folder-rename-and-delete.md D1, D3). Total: a row written without one is `synced`, because a folder the server just told us about is confirmed. Four values carry six states — `pending` covers a create and a rename in flight, `failed` covers a failed rename and a failed delete — so every guard and every transition predicate names the pair, never this field alone.
        */
-      syncStatus?: MailboxSyncStatus;
+      syncStatus: MailboxSyncStatus;
+      /**
+       * The path a recorded rename is moving this folder to. Absent unless a rename is in flight or has just failed, which is what tells a create in flight from a rename in flight (D2, D3). `fullPath` stays the path the server holds throughout, so a failed rename is this field cleared rather than a subtree of paths restored. Invariant: non-null only while `syncStatus` is `pending` or `failed`.
+       */
+      pendingPath?: String512;
       /**
        * Denormalized list of IMAP SPECIAL-USE designations (RFC 6154). Populated from the same `\Sent`, `\Drafts`, etc. attributes the server reports during LIST. Stored on the row to avoid an N+1 join when listing mailboxes.
        */
@@ -6540,6 +6544,7 @@ declare namespace Paths {
       from?: string;
       subject?: string;
       accountId?: Components.Schemas.UUID;
+      mailboxId?: Components.Schemas.UUID;
       muted?: boolean;
       category?: Components.Schemas.MessageCategory[];
       unread?: boolean;
@@ -7320,6 +7325,8 @@ Field filters: `from` and `subject` each match one field, which the single `quer
 
 Account scope: `accountId` narrows every mode to the mailboxes of one account. The scope is built from the account's own mailboxes, so the listing, the count and the search all answer over the same set. Without it the listing is the cross-account aggregate.
 
+Folder scope: `mailboxId` narrows the same scope to one folder, and composes with `accountId` as a further AND — a folder of another account leaves the scope empty and matches nothing. It is how a caller asks what one folder holds of a cross-account search, counted in the same conversations the unscoped listing renders. A folder the scope already excludes — Trash, a muted one, one of a muted account — stays excluded.
+
 Muted senders: `muted=false` excludes rows whose From address is muted, `muted=true` returns only those, and omitting it filters nothing. Muting is a property of the address rather than a column on the row, so this is the one predicate that reaches outside the ThreadMessage table; it applies to the listing and the `count` alike, which is what lets a caller that hides muted mail state a number that is the size of what it renders.
 
 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.
@@ -8154,6 +8161,8 @@ Field filters: `from` and `subject` each match one field, which the single `quer
 
 Account scope: `accountId` narrows every mode to the mailboxes of one account. The scope is built from the account's own mailboxes, so the listing, the count and the search all answer over the same set. Without it the listing is the cross-account aggregate.
 
+Folder scope: `mailboxId` narrows the same scope to one folder, and composes with `accountId` as a further AND — a folder of another account leaves the scope empty and matches nothing. It is how a caller asks what one folder holds of a cross-account search, counted in the same conversations the unscoped listing renders. A folder the scope already excludes — Trash, a muted one, one of a muted account — stays excluded.
+
 Muted senders: `muted=false` excludes rows whose From address is muted, `muted=true` returns only those, and omitting it filters nothing. Muting is a property of the address rather than a column on the row, so this is the one predicate that reaches outside the ThreadMessage table; it applies to the listing and the `count` alike, which is what lets a caller that hides muted mail state a number that is the size of what it renders.
 
 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.