[miguel-heygen]

What

The first-use Chrome download now runs one step above normal CPU priority, so a busy Windows PC no longer turns it into a many-minute wait.

Why

On a busy Windows machine the download barely moved. Every small disk write in Node's file stream queues for CPU behind whatever else is running, so the transfer crawled at a few hundred KB/s. Data kept arriving, so the 60 s stall check never fired, and a person just saw Still getting Chrome ready for ten minutes or more while the process used about 2 s of CPU.

Plain curl fetched the same file in about 3 s under the same load, and a Node download that doesn't write to disk took about 4 s.

How

renderSetupWorker.ts raises its own priority in browser-install mode only. That process lives for the download and unzip, and spends nearly all of it waiting. Most Unix systems refuse this without privileges, and the install then runs at normal priority as it does today, which is why that refusal is not an error.

I chose this over changing how the file is written because the write happens inside @puppeteer/browsers, and install() has no option for it.

Test plan

Measured on a 4 vCPU windows-latest runner with 12 busy-loop node processes, 119.5 MB:

Download	Result
Node write stream, default buffer	0.29 MB/s, stopped at 150 s
@puppeteer/browsers install(), no unzip	0.40 MB/s, stopped at 150 s
Write stream, 8 MiB buffer	10.8 s
Synchronous writes	6.7 s
install() at this priority	1.1 s

• renderSetupWorker.priority.test.ts: 7 passed, 3 runs in a row on a Linux box.

fails without the fix: "the Chrome install runs one step above normal priority" in renderSetupWorker.priority.test.ts, with the priority call removed at this head: 1 failed, 6 passed.

browser ensure built from source, same runner and load, one run each:

Build	Result
main	no install, killed by my limit at 617 s
This branch	Ready to render in 24 s, exit 0

hyperframes@0.9.18 browser ensure under that load also never finished: killed by my limit at 900 s, and again at 420 s.

Not exercised yet:

• Windows 11. The runner is Windows Server, which schedules differently, so a desktop PC may see a smaller difference.
• A Mac or Linux box under load. There the priority request is usually refused, so nothing changes.
• The unzip step on its own: system tar took 16 s under the same load and runs in a child process.

No visible change

No interface changes. The only difference a person sees is a shorter wait on first use.

Size

43 lines, most of them tests. It is a lone fix on purpose: no open PR touches this worker, and the change is one priority call.

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 104 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

Unstable (2)

• seqrotatenudge-none-pct-r0-root-z100: tracking 0.03, pressJump 0, drop 0, reload 3.03, render 0.04, renderKey -, undo false, teleport true / tracking 0.03, pressJump 0, drop 0, reload 0, render 0.08, renderKey -, undo true, teleport true / tracking 0.03, pressJump 0, drop 0, reload 0, render 0.08, renderKey -, undo true, teleport true
• seqab-none-center-r0-root-z100: tracking 0.03, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.03, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.03, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true

[heygengenesis]

Reviewed at d260c3be. Requesting changes. The one blocker is in the PR body, not the code.

Blocker

• The body has no fails without the fix: line. Lane rule: a fix PR must name the test that fails without the fix on a line that starts with fails without the fix:. Here the test is named only in prose under the Test plan ("…fails without the fix, and it is the only one that does"). The marker in the test file's comment doesn't count. Add a line such as:
  fails without the fix: renderSetupWorker.priority.test.ts > "the Chrome install runs one step above normal priority"
  Changing only the body doesn't change the head. I'll approve this same head once the line is there.

What I verified (the code is ready to approve)

• The claim holds. With core built locally, renderSetupWorker.priority.test.ts passes 7/7 at head. With renderSetupWorker.ts from main, exactly one test fails: "the Chrome install runs one step above normal priority".
• Coverage: every Chrome download goes through the browser-install worker (manager.ts → installInChild → runRenderSetupWorker("browser-install")). So the raised priority reaches browser ensure and the first-render install alike. mode === "browser" (ensureBrowser) only downloads through that same child.
• Refusals: EPERM and EACCES on Unix stay silent and the install still runs, as before. Other errors are still reported, now worded per mode. The refusal test checks both.
• The lint priority behaviour is unchanged. The refactor only parameterizes lowerPriority.
• All CI workflows on this head have completed green. The one CI run still in progress at review time was a duplicate.

Non-blocking

• On Windows, ABOVE_NORMAL_PRIORITY_CLASS is not inherited by child processes. Only IDLE and BELOW_NORMAL are. So the system tar unzip, which takes 16 s under load according to your notes, still runs at normal priority. That matches your "not exercised" note. Just confirming the fix covers only the download.

[heygengenesis]

Re-reviewed at d260c3be. Approved.

• The blocker is resolved. The body now has: fails without the fix: "the Chrome install runs one step above normal priority" in renderSetupWorker.priority.test.ts … 1 failed, 6 passed. This matches my local run. With renderSetupWorker.ts from main, exactly that test fails, 1 failed and 6 passed. At head, all 7 pass.
• The head is unchanged since my last review, so the code checks and green CI from that review still apply.
• My non-blocking note still stands: on Windows, ABOVE_NORMAL priority isn't passed to child processes, so the tar unzip still runs at normal priority.