`mocker images` shows `Zero KB` / `in 0 sec` for every image — SIZE and CREATED never populated

[KennethWKZ]

mocker version: 0.7.2 (Homebrew) — macOS, Darwin 25.5.0, arm64

Summary

mocker images reports Zero KB in SIZE and in 0 sec in CREATED for every image, including ones pulled weeks earlier. Both columns appear to render an unset zero value rather than real data.

Reproduction

$ mocker images
REPOSITORY                                     TAG         IMAGE ID       CREATED    SIZE
ctxonly                                        latest      sha256:bdfd1   in 0 sec   Zero KB
docker.io/library/neo4j                        5.26        sha256:bc271   in 0 sec   Zero KB
docker.io/library/caddy                        latest      sha256:844f6   in 0 sec   Zero KB
ghcr.io/apple/container-builder-shim/builder   0.13.0      sha256:25be1   in 0 sec   Zero KB
docker.io/library/alpine                       3.20        sha256:d9e85   in 0 sec   Zero KB
...

Every row, 14 of 14. docker.io/library/caddy:latest was pulled well before this session and is ~22 MB.

The data is available from the backend

container image ls exposes only NAME / TAG / DIGEST, so a listing built from it alone has nothing to populate these columns with. But container image inspect has both:

$ container image inspect docker.io/library/caddy:latest
[ { "configuration": {
      "creationDate": "2026-06-22T20:12:24Z",
      ...
    },
    "id": "844f60b6...",
    "variants": [ { ... "size": 22731608 } ] } ]

creationDate is the real timestamp, and the variants[0] descriptor size of 22731608 (21.7 MB) matches the expected size for that image. So both columns are fillable — per-image inspect, or caching the values at pull/build time to avoid N inspect calls on a large listing.

Secondary: unknown should not render as a confident zero

Even where a value genuinely cannot be determined, Zero KB and in 0 sec are misleading — they read as measurements. <unknown> or - (upstream uses N/A) would make the gap obvious. As filed, the output prompted a real "are my images corrupt?" investigation before the cause turned out to be cosmetic.

Related: #69, #70, #71, #72, #73.

[KennethWKZ]

Correction to the "data is available from the backend" section above — I understated how available it is.

I wrote that container image ls exposes only NAME / TAG / DIGEST and that mocker would need per-image container image inspect calls to fill these columns. That is wrong. container image ls -v already returns both fields for every image in a single call:

$ container image ls -v
NAME       TAG    INDEX DIGEST  OS     ARCH   VARIANT  FULL SIZE  CREATED                          MANIFEST DIGEST
ctxonly    latest bdfd17c26c85  linux  arm64           43.3 MB    2026-08-04T06:59:05.618401180Z   e7540fba1824
alpine     3.20   d9e853e87e55  linux  amd64           3.6 MB     2026-04-16T23:53:26.803599608Z   c64c687cbea9
alpine     3.20   d9e853e87e55  linux  arm64  v8       4.1 MB     2026-04-16T23:53:24.896953537Z   45e09956dc66

--format json carries the same values as variants[].size plus configuration.creationDate:

{ "digest": "sha256:c64c687c...", "platform": {"architecture": "amd64", "os": "linux"}, "size": 3631956 }

So no N+1 inspect calls and no caching at pull/build time are needed — a single container image ls -v (or --format json) supplies SIZE and CREATED for the whole listing.

One thing to decide when wiring it up: the backend reports per-variant sizes, so a multi-arch image like alpine:3.20 yields four rows (amd64 3.6 MB, arm/v6 3.4 MB, arm/v7 3.1 MB, arm64/v8 4.1 MB). docker images shows one row per image with the host platform's size, which would mean selecting the variant matching the host architecture rather than summing.

[us]

fixed in #77, shipped in v0.8.0.

images reads real SIZE and CREATED from each image's manifest and config now — the same resolution image inspect was already doing, so both share one formula and can't drift.

docker.io/library/alpine:3.20 reports 4.1 MB / 3mo ago here instead of Zero KB / in 0 sec. your secondary point landed as well: when the metadata genuinely isn't in the local content store the column renders N/A, never a confident zero. thanks for the container image inspect pointer, that's exactly where the data came from.