@ouro.bot/cli 0.1.0-alpha.493 → 0.1.0-alpha.495
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/changelog.json +12 -0
- package/dist/mailroom/blob-store.js +7 -1
- package/package.json +1 -1
package/changelog.json
CHANGED
|
@@ -1,6 +1,18 @@
|
|
|
1
1
|
{
|
|
2
2
|
"_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.",
|
|
3
3
|
"versions": [
|
|
4
|
+
{
|
|
5
|
+
"version": "0.1.0-alpha.495",
|
|
6
|
+
"changes": [
|
|
7
|
+
"New regression bundle at `src/__tests__/heart/provider-replay-regressions.test.ts` that captures provider replay-rejection bug shapes in one place — documentation-as-test. Each entry cites the PR that fixed the shape and the runbook entry; future debuggers seeing a 4xx from a provider on what looks like a valid turn can grep this file first to see if the shape was already encountered. Currently bundles the MiniMax-M2.7 inline-`<think>`-plus-tool_calls case (#612), the reused-tool_call_id-misordered-after-pruning case (#613), and a cross-reference stub for the event-id collision class (covered separately in session-events.test.ts). Also documents the contribution pattern: capture the failing shape, write the test BEFORE the fix, land the fix, verify the test passes, cite the PR. Linked from `docs/known-issues-and-recovery.md` so operators triaging a similar bug land on the test bundle by default."
|
|
8
|
+
]
|
|
9
|
+
},
|
|
10
|
+
{
|
|
11
|
+
"version": "0.1.0-alpha.494",
|
|
12
|
+
"changes": [
|
|
13
|
+
"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."
|
|
14
|
+
]
|
|
15
|
+
},
|
|
4
16
|
{
|
|
5
17
|
"version": "0.1.0-alpha.493",
|
|
6
18
|
"changes": [
|
|
@@ -9,7 +9,13 @@ const MESSAGE_INDEX_PREFIX = "message-index";
|
|
|
9
9
|
const MESSAGE_INDEX_SORT_MAX_MS = 9_999_999_999_999;
|
|
10
10
|
const MESSAGE_INDEX_SORT_WIDTH = 13;
|
|
11
11
|
const MESSAGE_INDEX_NO_SOURCE = "~";
|
|
12
|
-
|
|
12
|
+
// Bumped from 20s after Slugger's HEY-corpus validation revealed that
|
|
13
|
+
// real-world mail bodies (HTML-heavy booking confirmations, MBOX-imported
|
|
14
|
+
// large messages) regularly exceed the original 20s ceiling. 60s with 2
|
|
15
|
+
// attempts = 120s max wait, which is closer to what Azure Blob actually
|
|
16
|
+
// needs for cold reads of a few-MB message body. Index reads still fit
|
|
17
|
+
// comfortably in this budget.
|
|
18
|
+
const DEFAULT_BLOB_OPERATION_TIMEOUT_MS = 60_000;
|
|
13
19
|
const DEFAULT_BLOB_DOWNLOAD_ATTEMPTS = 2;
|
|
14
20
|
const DEFAULT_MESSAGE_FETCH_CONCURRENCY = 20;
|
|
15
21
|
const DEFAULT_MESSAGE_INDEX_BACKFILL_CONCURRENCY = 8;
|