Files
sencho/backend
Anso a1caf6b0dd fix(resources): use daemon-reported reclaimable image bytes (#1154)
* fix(resources): use daemon-reported reclaimable image bytes

The Reclaim banner summed per-image `VirtualSize` (or `Size`) across
every image with no running container. That counts shared base layers
once per image, so an unused base layer of 1 GB shared across ten builds
showed up as 10 GB of "prunable" space. The actual prune frees the
layer once and reports a much smaller `SpaceReclaimed`, leaving the
banner and the post-prune toast badly out of step.

Prefer Docker's own `ImageUsage.Reclaimable` (API v1.44+), which is the
exact value `docker system df` displays. Older daemons fall back to the
Docker CLI's internal formula: `LayersSize - sum(Size - SharedSize)`
for in-use images, clamped to 0, skipping any image Docker flags with
the -1 unknown-size sentinel.

Verified against a live daemon: the banner now matches
`docker system df`'s IMAGES RECLAIMABLE byte-for-byte.

* fix(resources): treat SharedSize=-1 as 0 in fallback, don't drop in-use bytes

The fallback formula is `LayersSize - used`. The previous version skipped
any active image whose VirtualSize or SharedSize was -1 (Docker's
"unknown" sentinel). Skipping leaves the image's bytes out of `used`,
which reads back as reclaimable -- the exact inflation the PR set out
to fix, just on older daemons.

Treat SharedSize=-1 (or absent) as 0 so the image's full size counts as
in-use, and only skip when no usable size is available at all
(VirtualSize and Size both unknown). Under-reporting reclaimable is the
safe direction; over-reporting was the original bug.

Add a test for the SharedSize=-1 case with Size known, and rename the
existing test so it reflects what is actually being asserted now.

Addresses Codex audit blocker on PR #1154.
2026-05-22 02:40:06 -04:00
..