mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-03 04:38:33 +00:00
Vance IngallsandClaude Sonnet 5
b3f244a7e9
Found while testing the previous commit's OOM-drops-to-1-worker fallback end-to-end: the producer's deployed runtime is Bun (JavaScriptCore), not Node (V8) — see packages/gcp-cloud-run/Dockerfile's `bun dist/server.js` entrypoint. All 7 MEMORY_EXHAUSTION_ERROR_PATTERNS are V8-specific allocation failure signatures; JSC's equivalent for the same single-oversized-allocation RangeErrors is the bare string "Out of memory" (verified against real Bun behavior), which none of them match. Without this, isMemoryExhaustionError returns false for genuine production OOM, so the memory-specific worker-count reduction just added would never actually engage where it's deployed — every OOM would fall through to the generic capture_error retry path instead. Matches the FULL (trimmed) message only, not merely a substring — same rationale as the existing V8 patterns' comment: "out of memory" also appears in benign WebGL/GPU console noise that must not trip this classifier. Verified end-to-end from a script inside the producer workspace (importing the real @hyperframes/engine source, not a stale globally-cached npm dist a script outside the workspace would otherwise resolve to): a genuine Bun RangeError from new Uint8Array(Number.MAX_SAFE_INTEGER) now correctly classifies as memory exhaustion and drives both resolveInversionRetryPlan and resolveParallelRouterRetryPlan down to workerCount=1 on retry. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>