@remit/api-openapi-spec 0.0.46 → 0.0.48

package/openapi.json

@@ -3238,6 +3238,16 @@
                 }
               }
             }
+          },
+          "409": {
+            "description": "The same flat 409 body, for a message whose folder and uid do not name the same message.\n\n`code: \"message_placement_unsettled\"` — the message is mid-move, so its row names the destination folder while its uid still belongs to the source; acting on that pair would hit whatever the destination holds at that uid. `details` carries `accountId`, `messageId` and `reason`, one of: `in_flight` (the move is still running, and the same request succeeds once it confirms) or `unverified` (the move gave up without confirming, so where the message sits is unknown until the folder is resynced).",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "$ref": "#/components/schemas/ApiError"
+                }
+              }
+            }
           }
         },
         "requestBody": {
@@ -7825,6 +7835,16 @@
         ],
         "description": "Header-derived message category. Set by classifyByHeaders during body-sync. Defaults to `uncategorized`, which covers both a message that has not been classified yet and one the classifier declined to categorize; `Message.classificationState` is what tells those apart."
       },
+      "RemitImap.MessageMutation": {
+        "type": "string",
+        "enum": [
+          "none",
+          "move",
+          "delete",
+          "copy"
+        ],
+        "description": "Which mutation a message's placement gave up on. Read it only while\n`syncStatus` is `abandoned` — outside that it is `none` and says nothing,\nthe way `originalUid` says nothing once a placement has settled\n(`docs/architecture/imap-mutations.md` R3).\n\nIt exists because a hand-back erases the evidence: the give-up puts `status`\nback to `active`, and `status` was the only field naming the mutation that\nwas outstanding. Without this the client can see that something was\nabandoned and cannot see what, which is how a move that gave up came to be\nexplained to the user as a failed delete."
+      },
       "RemitImap.MessageReferenceResponse": {
         "type": "object",
         "required": [
@@ -7890,7 +7910,8 @@
           "rfc822Size",
           "internalDate",
           "status",
-          "syncStatus"
+          "syncStatus",
+          "abandonedMutation"
         ],
         "properties": {
           "messageId": {
@@ -7952,10 +7973,20 @@
                 "$ref": "#/components/schemas/RemitImap.MessageSyncStatus"
               }
             ],
-            "description": "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.",
+            "description": "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.",
             "default": "synced",
             "readOnly": true
           },
+          "abandonedMutation": {
+            "allOf": [
+              {
+                "$ref": "#/components/schemas/RemitImap.MessageMutation"
+              }
+            ],
+            "description": "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.",
+            "default": "none",
+            "readOnly": true
+          },
           "authenticity": {
             "allOf": [
               {
@@ -7996,9 +8027,10 @@
         "enum": [
           "synced",
           "pending",
-          "failed"
+          "failed",
+          "abandoned"
         ],
-        "description": "Sync status for message move/delete operations"
+        "description": "Sync status for message move/delete operations. Read it as a pair with\n`MessageStatus`, never alone — the six placement states and the transitions\nbetween them are `docs/architecture/imap-mutations.md` R3."
       },
       "RemitImap.MintOutboxAttachmentInput": {
         "type": "object",
@@ -9537,7 +9569,8 @@
           "senderTrust",
           "muted",
           "status",
-          "syncStatus"
+          "syncStatus",
+          "abandonedMutation"
         ],
         "properties": {
           "threadMessageId": {
@@ -9697,7 +9730,15 @@
                 "$ref": "#/components/schemas/RemitImap.MessageSyncStatus"
               }
             ],
-            "description": "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."
+            "description": "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."
+          },
+          "abandonedMutation": {
+            "allOf": [
+              {
+                "$ref": "#/components/schemas/RemitImap.MessageMutation"
+              }
+            ],
+            "description": "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."
           },
           "accountId": {
             "allOf": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remit/api-openapi-spec",
-  "version": "0.0.46",
+  "version": "0.0.48",
   "description": "Remit API OpenAPI 3 document, generated from TypeSpec.",
   "exports": {
     ".": "./openapi.json",