mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-14 18:01:20 +08:00
Vance Ingalls
db5f149c53
PRINFRA-341 asks whether renders that exceed the heap advisory go on to OOM. That question is unanswerable against the current fleet: `workers_bound_by`, `workers_heap_based`, `workers_heap_limit_mb` and `workers_exceed_heap_advisory` are emitted on `render_complete` only, so 0 of 317,253 `render_error` events over the last seven weeks carry any of them. The cause is lifecycle, not intent: those props are read off `job.perfSummary`, which is assembled after a render succeeds. A render that dies mid-capture never reaches that assignment. Record sizing and sampled peak memory onto the job from the memory-sampler disposer instead, which the execution context runs on every exit including a throw, and read them on the failure path. Also prefer the sampler's running peak over the teardown RSS snapshot on both paths: `peak_memory_mb` previously reported whatever RSS happened to be at teardown, missing the mid-render spike the field exists to catch. Adds `peak_heap_used_mb` alongside it. Limitation, stated because it bounds what this buys: a fatal V8 `FATAL ERROR: Reached heap limit` aborts the process before any event is sent, so heap OOMs remain invisible to telemetry. This narrows the gap to failures that reach an error handler; it does not close it. Extracted `recordJobFailureMetrics` and `failureSizingTelemetry` so the copy is unit-testable rather than buried in a closure, and so handleRenderError's branch count does not grow. Tests cover the summary-to-event hop on the error path, peaks recorded when sizing was never computed, and an existing sizing not being blanked; all verified by mutation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>