test(install): drop stale kB-to-bytes scaling of resourceUsage().maxRSS

[robobun]

Fixes test/cli/install/bun-install-streaming-extract.test.ts red on main (every non-macOS lane, build 86466).

Failure

error: expect(received).toBeLessThan(expected)
Expected: < 536870912
Received: 333065486336

Cause

#36541 (b4aa3a0) added buffered extract does not hold the decompressed local tarball in memory, which scaled Subprocess.resourceUsage().maxRSS by 1024 on Linux/Windows under the assumption that it reports kilobytes there (raw ru_maxrss semantics). That assumption was already stale when it merged: #36087 (f68e504, merged ~11h earlier the same day) had normalised resourceUsage().maxRSS to bytes on every platform (RusageFields::maxrss multiplies by 1024 on non-Apple Unix; Windows stores PeakWorkingSetSize undivided). #36541 was branched before #36087 landed and was not rebased over it.

Dividing the CI values by the extra 1024 gives ~80-90 MB on release lanes and ~325 MB on the x64-asan lane, well under the 512 MB bound and consistent with the comment's stated baselines.

Fix

Drop the per-platform scaling: resourceUsage().maxRSS is already bytes everywhere. Tighten the existing > 0 lower bound to > 1 MiB so a future regression back to kilobytes trips that bound instead of making the upper bound vacuously pass (matches the unit guard in test/harness.ts's runFixtureMaxRSS).

The test's regression guard is unchanged: the old pre-decompress path that #36541 removed would still produce ~780 MB release / ~1 GB debug+ASAN peak RSS and fail the < 512 MB upper bound.

Test-only change; no src/ diff for fail-before.

Verification

bun bd test test/cli/install/bun-install-streaming-extract.test.ts
  10 pass, 0 fail

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 2811502c-0569-4733-8a91-42c07dc9b266

📥 Commits

Reviewing files that changed from the base of the PR and between bcd46e8 and 49d4075.

📒 Files selected for processing (1)

• test/cli/install/bun-install-streaming-extract.test.ts

---

Walkthrough

The streaming extraction test removes an unused isMacOS import. Its RSS assertion now checks byte-valued maxRSS directly, requires usage above 1 MiB, and retains the existing upper bound.

Changes

Streaming extraction test

Layer / File(s)	Summary
RSS validation update test/cli/install/bun-install-streaming-extract.test.ts	Removes the unused harness import. Updates RSS validation to use resourceUsage().maxRSS directly as bytes with a 1 MiB lower bound and the existing upper bound.

Suggested reviewers: jarred-sumner

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the removal of stale maxRSS scaling in the install test.
Description check	✅ Passed	The description explains the cause, fix, regression guard, and verification results, despite using different section headings than the template.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

LGTM — straightforward test-only fix for the CI failure on non-macOS lanes.

What was reviewed:

• Verified RusageFields::maxrss in src/spawn_sys/spawn_process.rs normalises to bytes on all platforms (×1024 on non-Apple Unix, PeakWorkingSetSize bytes on Windows), so the dropped scaling is correct.
• The new > 1 MiB lower-bound unit guard mirrors the existing pattern in test/harness.ts runFixtureMaxRSS.
• isMacOS import removal — no other uses in the file.

Extended reasoning...

Overview

This PR removes a stale per-platform * (isMacOS ? 1 : 1024) scaling of Subprocess.resourceUsage().maxRSS in one test (buffered extract does not hold the decompressed local tarball in memory) in test/cli/install/bun-install-streaming-extract.test.ts. The scaling was added in #36541 assuming raw ru_maxrss semantics, but #36087 had already landed hours earlier normalising maxRSS to bytes on every platform. The double-scaling made the received value ~325 GB on Linux/Windows, failing the < 512 MB upper bound. The fix drops the scaling, removes the now-unused isMacOS import, tightens the lower bound from > 0 to > 1 MiB as a unit guard, and updates the comment.

Security risks

None. Test-only change to an RSS assertion; no src/ changes, no untrusted-input handling.

Level of scrutiny

Low. This is a mechanical fix to a CI-red test with a well-documented root cause. I verified the underlying claim directly: RusageFields::maxrss() in src/spawn_sys/spawn_process.rs:200 multiplies by 1024 on non-Apple Unix and returns PeakWorkingSetSize (bytes) on Windows via WinRusage, so maxRSS is indeed bytes everywhere and the test-side scaling was double-counting. Dividing the CI failure value (333065486336) by 1024 gives ~325 MB, well under the 512 MB bound and consistent with the ASAN baseline the comment cites.

Other factors

• The > 1 MiB unit guard is copied verbatim from the established runFixtureMaxRSS helper in test/harness.ts:332, so it follows an existing convention rather than inventing a new threshold.
• The upper bound (< 2 * PAYLOAD_SIZE = 512 MB) is unchanged, so the regression the test guards against (~780 MB release / ~1 GB ASAN with the old pre-decompress path) still fails it.
• No prior reviews or outstanding comments on the PR timeline.
• PR states bun bd test passes locally with 10/10.