@remit/api-openapi-types 0.0.51 → 0.0.52

package/package.json

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

package/types.d.ts

@@ -190,9 +190,24 @@ current enum emitter anyway, so the wire contract uses the bare form.
      */
     export type MessageStatus = "active" | "deleting" | "deleted" | "moving";
     /**
-     * Sync status for message move/delete operations
+     * Sync status for message move/delete operations. Read it as a pair with
+`MessageStatus`, never alone — the six placement states and the transitions
+between them are `docs/architecture/imap-mutations.md` R3.
      */
-    export type MessageSyncStatus = "synced" | "pending" | "failed";
+    export type MessageSyncStatus = "synced" | "pending" | "failed" | "abandoned";
+    /**
+     * Which mutation a message's placement gave up on. Read it only while
+`syncStatus` is `abandoned` — outside that it is `none` and says nothing,
+the way `originalUid` says nothing once a placement has settled
+(`docs/architecture/imap-mutations.md` R3).
+
+It exists because a hand-back erases the evidence: the give-up puts `status`
+back to `active`, and `status` was the only field naming the mutation that
+was outstanding. Without this the client can see that something was
+abandoned and cannot see what, which is how a move that gave up came to be
+explained to the user as a failed delete.
+     */
+    export type MessageMutation = "none" | "move" | "delete" | "copy";
     /**
      * Actionable placement verdict — the direction Remit decided to move a message. `leave` is not represented: a left-in-place verdict means the placement sub-model is absent.
      */
@@ -3371,9 +3386,13 @@ asking "is this slot free" never has to do the merging itself.
        */
       status: MessageStatus;
       /**
-       * Sync status of the underlying Message, projected at read time. Read it WITH `status`, never alone: `message-move`, `message-delete` and `message-copy` all write `failed` on an ordinary transient attempt before a redelivery that usually succeeds, so `failed` by itself does not mean a mutation gave up. One pair does prove one: `active` + `failed`, written only by `abandonDelete` — a delete Remit refused to run and handed back. Nothing else here is decidable. A move that gave up leaves `moving` + `failed`, the same pair its first dropped connection leaves; a delete that exhausted its retries is repaired to `active` + `synced` and reads as settled; `flag-push` and `placement-move-push` never write either field.
+       * Sync status of the underlying Message, projected at read time. Read it WITH `status`, never alone (imap-mutations R3): `message-move`, `message-delete` and `message-copy` all write `failed` on an ordinary transient attempt before a redelivery that usually succeeds, so `failed` never means a mutation gave up. Give-up is `active` + `abandoned`, and that pair is decidable on its own — the row has been put back on a placement the server holds and nothing else is coming for it. A mutation that exhausted its retries and was repaired against IMAP settles to `active` + `synced` and reads as settled.
        */
       syncStatus: MessageSyncStatus;
+      /**
+       * Which mutation gave up on the underlying Message, projected at read time. Read it only where `syncStatus` is `abandoned`; `none` otherwise. This is what lets a surface name the operation that actually failed — before it existed, a move that handed back and a delete that was refused were the same two values on the wire, and the client called both a failed delete.
+       */
+      abandonedMutation: MessageMutation;
       /**
        * Account identifier attached at read time via a mailboxId→accountId map. Present on rows returned by `GET /threads`; absent on rows from per-mailbox endpoints (clients can resolve from the mailbox cache).
        */
@@ -4394,9 +4413,13 @@ either way and cannot tell which it received.
        */
       status: MessageStatus;
       /**
-       * 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.
+       * Sync status for move/delete operations, read as a pair with `status` (imap-mutations R3). 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, `failed` marks an attempt about to be redelivered, and `abandoned` marks a mutation that gave up.
        */
       syncStatus: MessageSyncStatus;
+      /**
+       * Which mutation gave up on this message. Meaningful only while `syncStatus` is `abandoned`; `none` everywhere else, so the absent state is a named value rather than a missing attribute. Written by the same transition that writes `abandoned`, because a hand-back sets `status` back to `active` and that is the field which named the mutation.
+       */
+      abandonedMutation: MessageMutation;
       /**
        * Original mailbox ID before move (for restore from trash)
        */
@@ -4573,9 +4596,13 @@ either way and cannot tell which it received.
        */
       status: MessageStatus;
       /**
-       * 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.
+       * Sync status for move/delete operations, read as a pair with `status` (imap-mutations R3). 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, `failed` marks an attempt about to be redelivered, and `abandoned` marks a mutation that gave up.
        */
       syncStatus: MessageSyncStatus;
+      /**
+       * Which mutation gave up on this message. Meaningful only while `syncStatus` is `abandoned`; `none` everywhere else, so the absent state is a named value rather than a missing attribute. Written by the same transition that writes `abandoned`, because a hand-back sets `status` back to `active` and that is the field which named the mutation.
+       */
+      abandonedMutation: MessageMutation;
       /**
        * Structured sender-authenticity signal derived from DKIM headers at classification time. Absent for messages classified before this field was introduced — absence means no signal.
        */
@@ -8617,6 +8644,7 @@ export type SenderTrust = Components.Schemas.SenderTrust;
 export type DisplayNameCorrespondence = Components.Schemas.DisplayNameCorrespondence;
 export type MessageStatus = Components.Schemas.MessageStatus;
 export type MessageSyncStatus = Components.Schemas.MessageSyncStatus;
+export type MessageMutation = Components.Schemas.MessageMutation;
 export type PlacementAction = Components.Schemas.PlacementAction;
 export type SemanticSearchChunkType = Components.Schemas.SemanticSearchChunkType;
 export type OutboxMessageStatus = Components.Schemas.OutboxMessageStatus;