@remit/api-openapi-spec 0.0.47 → 0.0.49

package/openapi.json

@@ -7687,7 +7687,8 @@
           "fullPath",
           "phase",
           "messagesTotal",
-          "messagesSynced"
+          "messagesSynced",
+          "highWaterMarkUid"
         ],
         "properties": {
           "mailboxId": {
@@ -7716,6 +7717,11 @@
             "format": "int32",
             "description": "Approximate number of messages synced. Computed as highWaterMarkUid − lastSyncUid (UID-range approximation; UIDs are sparse so this may undercount). Clamped to messagesTotal."
           },
+          "highWaterMarkUid": {
+            "type": "integer",
+            "format": "int64",
+            "description": "The highest UID ever seen in this mailbox. An arrival is a UID above the highest one seen; a total is not, because one message in and one out nets to zero. A mailbox that has never synced carries the sentinel 0 rather than an absent field."
+          },
           "lastSyncedAt": {
             "type": "integer",
             "format": "int64",
@@ -7835,6 +7841,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": [
@@ -7900,7 +7916,8 @@
           "rfc822Size",
           "internalDate",
           "status",
-          "syncStatus"
+          "syncStatus",
+          "abandonedMutation"
         ],
         "properties": {
           "messageId": {
@@ -7962,10 +7979,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": [
               {
@@ -8006,9 +8033,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",
@@ -9547,7 +9575,8 @@
           "senderTrust",
           "muted",
           "status",
-          "syncStatus"
+          "syncStatus",
+          "abandonedMutation"
         ],
         "properties": {
           "threadMessageId": {
@@ -9707,7 +9736,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.47",
+  "version": "0.0.49",
   "description": "Remit API OpenAPI 3 document, generated from TypeSpec.",
   "exports": {
     ".": "./openapi.json",