Repository navigation
fix(cli): check finishes on long projects with many video clips - #6270
Conversation
check loaded every video in the project at once. On a 500 s project with 137 clips of one 1440p source a single renderer reached 6.4 GB, the second sampling Chrome crashed, and a crashed puppeteer page never settles its calls, so the run sat until the 120 s deadline. - Load the check page in Studio's capture mode so only media near the playhead loads (peak renderer memory 15.75 GB -> 1.77 GB). - Read audio durations for the clip-fit audit from a detached element when the page has not loaded the one in the composition. - Settle every driver call with the page's crash or close, so a dead helper hands its samples back and a dead main page fails at once.
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verdict: APPROVE · 0 blocker · 1 important · 1 nit · head 16043914
- important —
Commentsratchet is red (not a required check): the PR adds 2 comment lines topackages/cli/src/commands/validate.tsand 3 topackages/cli/src/utils/checkBrowser.ts. Cut them, or move the explanation into names. - nit —
failWhenPageDiesonly wraps driver calls. If the main page crashes beforecreatePageDriver(auditClipDurations,collectTweenRecords,collectMotionBlurDrafts,checkBrowser.ts:342-350) or inabortedImagesStillBroken, the check still waits out the deadline.
Scope
I read all 4 files end to end and traced the capture-mode path: deferMediaUntilDue keeps src, the holdSeekBarrierUntilVideoLands barrier waits for a deferred clip at each sample, and missing_local_asset lint still catches missing files that are never fetched. I also checked the helper recovery on a rejected call. CI on this head: Test, Typecheck and Build are green. Two Studio edit-accuracy shards were still running when I posted. I could not run the tests locally because the core build was missing.
Edit accuracy: accurate 271 (base branch 271), smooth 171 of thoseThe gate passes. Quarantined, measured but not gated (0) Unstable (1)
|
What
hyperframes checknow finishes on long projects with many video clips. Before, a 500 s project with 137 clips of one 1440p source failed at the 120 s deadline.Why
checkloaded every<video>in the project at once. On that project one renderer reached 6.4 GB (all renderers together 15.75 GB). The second sampling Chrome crashed, and a crashed puppeteer page emitserrorbut never settles the calls pending on it, so the run waited out the idle deadline. The same project pinned to one Chrome passed, which is how the cause was found. Narrowing with--rangedid not help:--range 0,20 --samples 1failed the same way, because the page loads the whole project before any range applies.How
checkmarks its page with Studio's existing capture mode (hyperframes-studio-previewmeta,content="capture"), the mode Studio's own screenshot path uses. Only media near the playhead loads, so decoders no longer pile up.auditClipDurations) could no longer read the duration of audio the page never loaded, so it reads it from a detached element on the same source.createPageDriversettles every call with the page'serrororclose. A dead helper page now hands its samples back to the main page (the existing recovery path, which never ran for a hang), and a dead main page fails at once with "The page crashed".Not in this PR: splitting a long check into parallel time windows. A 500 s project now checks in about half a minute, so it is not needed yet. Printing the partial report when
checkis killed by a signal is a separate change.Test plan
Measured on a 4-core Linux box,
check --json, fixtures built for this (a 1440p H.264 source cut into many clips, synthetic audio):--range 0,20 --samples 1--timeout 15000Peak renderer memory on the first fixture went from 15.75 GB to 1.77 GB. The findings (code, severity, message) are identical before and after on the first three fixtures, compared against a one-Chrome run without the change.
The previous helper-crash test threw
Target closedfrom the seek, which real puppeteer does not do for a renderer crash. That is why the hang was not covered; the new test models the real behaviour (page emitserror, call stays pending).