fix(disk-space): promote 1024 MiB to 1.0 GiB in disk warnings#90247
Conversation
|
Codex review: needs maintainer review before merge. Reviewed June 4, 2026, 4:31 AM ET / 08:31 UTC. Summary PR surface: Source +3, Tests +9. Total +12 across 2 files. Reproducibility: yes. Current main's Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Next step before merge
Security Review detailsBest possible solution: Land the helper-level unit-selection fix with the boundary test, then close #90245 as fixed. Do we have a high-confidence way to reproduce the issue? Yes. Current main's Is this the best way to solve the issue? Yes. The clean fix is in the shared AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against 6082f01b971e. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +3, Tests +9. Total +12 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
formatDiskSpaceBytes tested the unrounded mib < 1024 but then rounded, so values in [1023.5, 1024) MiB printed the impossible "1024 MiB". Round before choosing the unit so they render as "1.0 GiB".
b8e2f0d to
1ce8d11
Compare
vincentkoc
left a comment
There was a problem hiding this comment.
No blocking findings.
Best-fix verdict: best. The shared formatDiskSpaceBytes helper is the right layer because the operator-facing low-disk warning consumes that formatter directly; call-site string patching would leave the boundary bug in place.
Alternatives considered: changing the update warning only would miss future helper callers; changing Doctor's separate formatter would be wrong because it intentionally floors threshold warnings.
Proof: local git diff --check, oxfmt, oxlint, focused Vitest; autoreview clean; GitHub CI exact head 1ce8d11 green.
Fixes #90245
Summary
formatDiskSpaceByteschose the unit on the unroundedmib < 1024but thenMath.round(mib)'d the MiB branch, so any value withmib ∈ [1023.5, 1024)printed the impossible"1024 MiB"instead of"1.0 GiB".[1023.5, 1024)boundary.This string is operator-facing: it appears in the low-disk warning from
createLowDiskSpaceWarningduring setup/update staging.Real behavior proof
Behavior addressed: the low-disk warning should never render
"1024 MiB"; values that round up to 1 GiB must read"1.0 GiB".Real environment tested: local checkout on current
main(ec3aa5def4), exercising the real exportedformatDiskSpaceBytesandcreateLowDiskSpaceWarningvianode --import tsx(the latter withfs.statfsSyncstubbed to report boundary free space, which is the only external input that path reads).Exact steps or command run after this patch:
plus
node scripts/run-vitest.mjs src/infra/disk-space.test.ts.Evidence after fix:
Before this patch the same input on
mainproduced"1024 MiB"(warning:"... 1024 MiB available; ...").Observed result after fix: boundary values render
"1.0 GiB";1023.4 MiBstill reads"1023 MiB"; existing420 MiB/1.5 GiBcases unchanged.What was not tested: no real volume was driven to exactly the boundary free-space; the disk read (
fs.statfsSync) is the single external dependency and was stubbed to the boundary value, while the formatting under test runs unmodified.Verification
node scripts/run-vitest.mjs src/infra/disk-space.test.ts→ 4 passed (incl. new boundary test)oxfmt --checkclean;oxlintclean;git diff --checkclean