@ouro.bot/cli 0.1.0-alpha.492 → 0.1.0-alpha.494

package/changelog.json

@@ -1,6 +1,18 @@
 {
   "_note": "This changelog is maintained as part of the PR/version-bump workflow. Agent-curated, not auto-generated. Agents read this file directly via read_file to understand what changed between versions.",
   "versions": [
+    {
+      "version": "0.1.0-alpha.494",
+      "changes": [
+        "Bump default Azure Blob operation timeout from 20s to 60s. Slugger's HEY-corpus validation against the booking-aware ranking from #608 surfaced a real issue: ranking and metadata are clean, but body fetches for targeted retrieval (`mail_thread`-style 'open this specific message') were timing out on real-world mail bodies. HEY mail with HTML-heavy booking confirmations regularly exceed the 20s ceiling on cold reads from Azure Blob. 60s with 2 attempts gives 120s max wait, which matches Azure's actual cold-read SLA for few-MB blobs while still bounding total wait. Index reads still fit comfortably in this budget. Existing test fixture for the timeout error message updated."
+      ]
+    },
+    {
+      "version": "0.1.0-alpha.493",
+      "changes": [
+        "Position-aware orphan-tool-result detection in `repairToolCallSequences`. Slugger's session was STILL hitting MiniMax error 2013 even after the alpha.492 inline-reasoning strip landed because the orphan check was global (a tool result was kept if its tool_call_id appeared in ANY assistant message in the conversation, regardless of order). After session pruning, a synthetic tool-result for a long-pruned tool_call ended up at sequence 86 referencing `call_function_utqogadgqp5h_1` while the assistant message that defined that id lived at sequence 88 — AFTER the tool result. MiniMax requires tool results to follow their matching assistant. The fix walks the conversation in order, tracking tool_call_ids only as they're encountered in assistant messages; tool results referencing ids that haven't been defined yet are removed. Regression test reproduces the exact misordered shape and asserts the misplaced tool result is dropped while the correctly-ordered one survives. This is the third and final layer of the empty-reply chain (#611 stripped the operator surface, #612 stripped the persisted content + load-time repair, #493 fixes orphan-detection ordering)."
+      ]
+    },
     {
       "version": "0.1.0-alpha.492",
       "changes": [

package/dist/heart/core.js

@@ -361,27 +361,39 @@ const TOOL_SCAN_BOUNDARY_ROLES = new Set(["assistant", "user"]);
 // 1. If an assistant message has tool_calls but missing tool results, inject synthetic error results.
 // 2. If a tool result's tool_call_id doesn't match any tool_calls in a preceding assistant message, remove it.
 // This prevents 400 errors from the API after an aborted turn.
+//
+// Position-aware: a tool result is orphaned when its tool_call_id hasn't been
+// defined by an assistant message AT THIS POSITION yet. MiniMax-M2.7 reuses
+// canonical tool_call_ids across turns, so the global-set check that this
+// function used previously kept misordered tool results that MiniMax then
+// rejected with error 2013 ("tool result's tool id not found"). Walking
+// in order matches what MiniMax actually enforces.
 function repairOrphanedToolCalls(messages) {
-    // Pass 1: collect all valid tool_call IDs from assistant messages
-    const validCallIds = new Set();
-    for (const msg of messages) {
+    // Pass 1: walk in order, accumulate seen tool_call_ids per-position, and
+    // mark tool results for removal if their id hasn't been defined yet.
+    const seenCallIds = new Set();
+    const removeIndices = [];
+    for (let i = 0; i < messages.length; i++) {
+        const msg = messages[i];
         if (msg.role === "assistant") {
             const asst = msg;
             if (asst.tool_calls) {
                 for (const tc of asst.tool_calls)
-                    validCallIds.add(tc.id);
+                    seenCallIds.add(tc.id);
             }
+            continue;
         }
-    }
-    // Pass 2: remove orphaned tool results (tool_call_id not in any assistant's tool_calls)
-    for (let i = messages.length - 1; i >= 0; i--) {
-        if (messages[i].role === "tool") {
-            const toolMsg = messages[i];
-            if (!validCallIds.has(toolMsg.tool_call_id)) {
-                messages.splice(i, 1);
+        if (msg.role === "tool") {
+            const toolMsg = msg;
+            if (!seenCallIds.has(toolMsg.tool_call_id)) {
+                removeIndices.push(i);
             }
         }
     }
+    // Splice from the end so earlier indices stay valid.
+    for (let i = removeIndices.length - 1; i >= 0; i--) {
+        messages.splice(removeIndices[i], 1);
+    }
     // Pass 3: inject synthetic results for tool_calls missing their tool results
     for (let i = 0; i < messages.length; i++) {
         const msg = messages[i];

package/dist/heart/session-events.js

@@ -336,18 +336,22 @@ function repairSessionMessages(messages) {
 }
 function repairToolCallSequences(messages, inlineReasoningStrippedCallIds = new Set()) {
     const normalized = messages.map(normalizeMessage);
-    const validCallIds = new Set();
-    for (const msg of normalized) {
-        if (msg.role !== "assistant")
-            continue;
-        for (const toolCall of msg.toolCalls)
-            validCallIds.add(toolCall.id);
-    }
+    // Position-aware orphan detection. A tool result is orphaned if there is
+    // no preceding assistant message in the array whose tool_calls contain the
+    // matching id. (The previous logic checked all assistant messages
+    // globally, which kept tool results that appeared BEFORE their matching
+    // assistant — invalid order — and triggered MiniMax error 2013 on replay.)
     let removed = 0;
+    const seenCallIds = new Set();
     const repaired = normalized.filter((msg) => {
+        if (msg.role === "assistant") {
+            for (const tc of msg.toolCalls)
+                seenCallIds.add(tc.id);
+            return true;
+        }
         if (msg.role !== "tool")
             return true;
-        const keep = msg.toolCallId !== null && validCallIds.has(msg.toolCallId);
+        const keep = msg.toolCallId !== null && seenCallIds.has(msg.toolCallId);
         if (!keep)
             removed++;
         return keep;

package/dist/mailroom/blob-store.js

@@ -9,7 +9,13 @@ const MESSAGE_INDEX_PREFIX = "message-index";
 const MESSAGE_INDEX_SORT_MAX_MS = 9_999_999_999_999;
 const MESSAGE_INDEX_SORT_WIDTH = 13;
 const MESSAGE_INDEX_NO_SOURCE = "~";
-const DEFAULT_BLOB_OPERATION_TIMEOUT_MS = 20_000;
+// Bumped from 20s after Slugger's HEY-corpus validation revealed that
+// real-world mail bodies (HTML-heavy booking confirmations, MBOX-imported
+// large messages) regularly exceed the original 20s ceiling. 60s with 2
+// attempts = 120s max wait, which is closer to what Azure Blob actually
+// needs for cold reads of a few-MB message body. Index reads still fit
+// comfortably in this budget.
+const DEFAULT_BLOB_OPERATION_TIMEOUT_MS = 60_000;
 const DEFAULT_BLOB_DOWNLOAD_ATTEMPTS = 2;
 const DEFAULT_MESSAGE_FETCH_CONCURRENCY = 20;
 const DEFAULT_MESSAGE_INDEX_BACKFILL_CONCURRENCY = 8;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ouro.bot/cli",
-  "version": "0.1.0-alpha.492",
+  "version": "0.1.0-alpha.494",
   "main": "dist/heart/daemon/ouro-entry.js",
   "bin": {
     "cli": "dist/heart/daemon/ouro-bot-entry.js",