Files
Triple-C/app/src/lib/formatBytes.test.ts
T
shadow-testandClaude Opus 5 611f67cca7 Fix what review found in the Disk section
Safety:

- `destroy`'s rollback-pin arm took a tag over IPC and interpolated it
  straight into an image reference it then removed. `tag: "latest"` named
  the project's live snapshot, deleted under a dialog saying "rollback
  pin". It is the one destructive variant carrying a free-form string, so
  it now goes through `parse_rollback_tag`.
- The compaction's scratch container was named `triple-c-scrub-*`, which
  is what the scrub reclaim bucket hunts and force-removes. A reclaim from
  a second window would have destroyed the container a running compaction
  was about to commit. It gets `triple-c-compact-*`, swept at the start of
  the next compaction rather than from a bucket anything else can fire.
- Deleting a home or config volume only refused a *running* container, but
  a stopped one still pins its volumes — the resting state of every
  project ever started — so the user typed the project name and met a raw
  409. The container is now removed first and `loses` says so.

Correctness:

- The compaction Dockerfile emitted no `LABEL`, so the flattened
  intermediate could never match the sweep's `dangling` + `triple-c.managed`
  filter that three cleanup paths rely on. Verified on Docker 29.7.2 that
  the label lands on the final stage, the build still yields one layer, and
  untagging the staging tag after the commit leaves the committed snapshot
  intact and startable.
- `snapshot_commit_layers` silently meant something else when
  `triple-c.base-image-id` was absent — the normal case for a pre-label
  project — counting the base's own layers and letting a never-recreated
  project qualify for compaction. `base_lineage_known` now carries that,
  the column says "unknown", and the plan does not offer the rewrite.
- `destroy` returned a `ReclaimResult` wearing a `ReclaimTarget` that named
  work it had not done (a home-volume deletion came back as
  `OrphanVolume`). Split into `target` / `destroyed`, exactly one set.
- `formatBytes` ran `toFixed` after the divide loop, so 999,999 rendered as
  "1000.0 KB" — in the app's only byte formatter, in a panel full of
  near-boundary sizes.
- `is_base_image_reference` split on the first colon, so a registry port
  ate the repo name.

UI:

- `snapshot_above_base_bytes: null` — deliberately unmeasurable — rendered
  as "0 B", the one guessed number in the table.
- Layer count was flagged by colour alone; it now says "stacked".
- The tick list survived a reclaim, so the same call could be re-fired at
  objects that no longer existed. The plan is dropped after any action and
  the panel says the totals predate it.
- `setReport` landed before the plan call was awaited, so a plan failure
  rendered fresh totals above the previous scan's rows.
- Both confirmation modals unmounted before awaiting, making the entire
  busy path dead code during multi-second work.
- `buildx du` failures silently showed `docker system df`'s under-reported
  build-cache figure with no explanation.
- Tooltip text reached no assistive tech, so two headers announced as
  "Help"; hardcoded input id; error-toned glyph in warning-toned panels;
  `sweepOrphanedSnapshots` and `clearOutcome` had no callers.
- Four docstrings claimed things the code did not do, and two tests were
  named for behaviour they did not assert.

Tests: 513 frontend (was 502), 370 Rust (was 365).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc
2026-08-23 09:51:09 -07:00

106 lines
4.6 KiB
TypeScript

import { describe, it, expect } from "vitest";
import { formatBytes, formatBytesCeiling, formatBytesDelta } from "./formatBytes";
describe("formatBytes", () => {
it("defaults to base 1000, because that is what Docker prints", () => {
// The Disk panel exists to explain `docker system df`, which formats with
// `units.HumanSize` — base 1000. Showing 26.1 GB against a terminal saying
// 28.0 GB for the same build cache reads as a bug in the panel.
expect(formatBytes(28_000_000_000)).toBe("28.0 GB");
expect(formatBytes(1_000)).toBe("1.0 KB");
expect(formatBytes(1_500_000)).toBe("1.5 MB");
expect(formatBytes(12_273_392_374)).toBe("12.3 GB");
});
it("leaves whole bytes without a decimal point", () => {
expect(formatBytes(0)).toBe("0 B");
expect(formatBytes(512)).toBe("512 B");
expect(formatBytes(999)).toBe("999 B");
});
it("reproduces the Project Home convention exactly under `binary`", () => {
// Three modules import `projects/home/format.ts#formatBytes`, which is now
// this function. Its output had to be byte-identical or re-pointing it
// would have quietly changed every file listing in the app.
expect(formatBytes(1023, { binary: true })).toBe("1023 B");
expect(formatBytes(1024, { binary: true })).toBe("1.0 KB");
expect(formatBytes(1024 * 1024, { binary: true })).toBe("1.0 MB");
expect(formatBytes(1024 * 1024 * 1024, { binary: true })).toBe("1.0 GB");
expect(formatBytes(1_610_612_736, { binary: true })).toBe("1.5 GB");
});
it("reproduces the migration convention exactly by default", () => {
// `migrationCopy.formatDataSize` is now a call to this, and its output is
// asserted in MigrateContainerModal.test.tsx.
expect(formatBytes(41_000_000)).toBe("41.0 MB");
expect(formatBytes(3_800_000_000)).toBe("3.8 GB");
});
it("labels binary units honestly when asked to", () => {
expect(formatBytes(1024, { binary: true, iec: true })).toBe("1.0 KiB");
expect(formatBytes(1024 ** 3, { binary: true, iec: true })).toBe("1.0 GiB");
});
it("climbs to TB rather than showing five-digit gigabytes", () => {
expect(formatBytes(2_500_000_000_000)).toBe("2.5 TB");
});
it("promotes the unit when rounding lands on a whole step", () => {
// `toFixed` runs after the divide loop, so a value just under a boundary
// rounds up into a unit the loop had already ruled out. This is the app's
// only byte formatter and the panel is full of near-boundary sizes.
expect(formatBytes(999_999)).toBe("1.0 MB");
expect(formatBytes(999_999_999)).toBe("1.0 GB");
expect(formatBytes(999_999_999_999)).toBe("1.0 TB");
expect(formatBytes(1_048_575, { binary: true })).toBe("1.0 MB");
// Just below the rounding threshold it must NOT promote.
expect(formatBytes(999_949)).toBe("999.9 KB");
expect(formatBytes(999_400, { precision: 0 })).toBe("999 KB");
// The top unit has nowhere to go: it renders a whole step rather than
// running off the end of the unit array.
expect(formatBytes(999_999_999_999_999_999)).toBe("1000.0 PB");
});
it("renders an em dash for a size the daemon did not compute", () => {
// Docker reports -1 for "not calculated" on shared sizes and volume ref
// counts. `NaN GB` in the middle of a table is worse than nothing.
expect(formatBytes(-1)).toBe("—");
expect(formatBytes(NaN)).toBe("—");
expect(formatBytes(Infinity)).toBe("—");
});
it("honours a requested precision", () => {
expect(formatBytes(1_234_567_890, { precision: 2 })).toBe("1.23 GB");
expect(formatBytes(1_234_567_890, { precision: 0 })).toBe("1 GB");
});
});
describe("formatBytesDelta", () => {
it("signs a figure that is being added rather than measured", () => {
// "Next commit adds +868.0 MB" — the sign is what makes it read as a cost
// about to be incurred rather than a size already on disk.
expect(formatBytesDelta(868_000_000)).toBe("+868.0 MB");
expect(formatBytesDelta(0)).toBe("+0 B");
});
it("does not sign an unknown", () => {
expect(formatBytesDelta(-1)).toBe("—");
});
});
describe("formatBytesCeiling", () => {
it("says 'up to', because a compaction's yield is a bound not a promise", () => {
// Every other figure in the Disk panel is measured. This one cannot be
// known until the rewrite runs, and rendering it through a separate
// function is what stops it being read as a guarantee.
expect(formatBytesCeiling(5_100_000_000)).toBe("up to 5.1 GB");
});
it("refuses to imply a saving when there is no bound to give", () => {
expect(formatBytesCeiling(0)).toBe("an unknown amount");
expect(formatBytesCeiling(-1)).toBe("an unknown amount");
});
});