[miguel-heygen]

What

audioMixer.urlRead.test.ts › reads many clips of one URL at once, since the wait is on the network and not the CPU now passes on machines with 32 or more cores.

Why

The test checks that clips read from a URL are not held to the CPU-sized prepare limit. The mixer has two limits:

• Local clips: max(2, floor(cores / 2)).
• URL clips: a fixed 16.

The test asserts that the peak number of open reads is above the local limit. On 32 cores the local limit is also 16, and the URL limit holds the peak at exactly 16, so the test failed on main (expected 16 to be greater than 16). It failed the same way on any box with more cores.

Related work

None.

How

The test file pins the core count at 8 by mocking cpus from node:os, as audioMixer.order.test.ts already does. The local limit is then 4, whatever the machine, and the assertion checks the same claim everywhere.

Test plan

fails without the fix: reads many clips of one URL at once, since the wait is on the network and not the CPU (audioMixer.urlRead.test.ts) fails on main on a 32-core box with expected 16 to be greater than 16, and passes with this change.

• On a 32-core Linux box, where main fails this test: 3 runs in a row, 5 of 5 pass each time.
• Break check: I put URL clips on the CPU-sized limit (the bug this test guards against), and the test fails. Then I restored it.
• Unit tests added/updated: no new test. One existing test's environment is now fixed.
• Manual testing performed: not applicable, test-only change.
• Documentation updated (if applicable): not applicable.
• Comments follow CONTRIBUTING.md "Comments": no comments added.

Size

8 lines, on purpose: this is a one-test environment fix. The sound PR it was found on has already merged, and none of my open PRs touches this file.

[heygengenesis]

Requesting changes at 804302b3 for one reason only: the body has no fails without the fix: line. This lane requires that line on every fix PR, and that includes test-environment fixes.

The evidence already exists in the Test plan. Add it as a line in this form:

fails without the fix: packages/engine/src/services/audioMixer.urlRead.test.ts › reads many clips of one URL at once, since the wait is on the network and not the CPU (on main, on 32+ cores: expected 16 to be greater than 16)

The code itself is fine, and I'd approve it once the line is in:

• audioMixer.ts:213 sets the local prepare limit from cpus().length when the module loads. vi.mock is hoisted above that import, so the mixer sees 8 cores and gets a local limit of 4. The assertion on line 289 calls the same mocked cpus(), so both sides agree, and the fixed URL limit of 16 clears 4 on any machine.
• The other cpus() calls the mixer can reach (videoFrameExtractor and parallelCoordinator) read only .length, so the {} entries are safe.
• This matches the existing mock in audioMixer.order.test.ts.
• CI and every other check on this head pass.

[heygengenesis]

Approve at 804302b3. The body now names the failing test on a fails without the fix: line: audioMixer.urlRead.test.ts › reads many clips of one URL at once…, which fails on main on 32+ cores with "expected 16 to be greater than 16". The head is unchanged, so my earlier code review still holds and CI is green. Nothing blocks this.