fix(mutate): close layer readers immediately after extracting layer#2190
fix(mutate): close layer readers immediately after extracting layer#2190caxu-rh wants to merge 2 commits into
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
16c6930 to
9746947
Compare
|
Sorry for the delay - resolved the CLA coverage. The diff looks kind of confusing, but this is essentially nesting the loop body into an anonymous function. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2190 +/- ##
===========================================
- Coverage 71.67% 52.93% -18.75%
===========================================
Files 123 165 +42
Lines 9935 11211 +1276
===========================================
- Hits 7121 5934 -1187
- Misses 2115 4562 +2447
- Partials 699 715 +16 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
In mutate.extract, the closing of layerReader resources is deferred from inside a `for` loop. As a result, the layerReaders are left open until all layers are processed, which may accumulate on images with many layers. Intorduce an inner function/closure to contain the layerReader and operations that use it, so that it can be released immediately after the current layer has been processed. Signed-off-by: Caleb Xu <caxu@redhat.com>
9746947 to
72938b5
Compare
…464) ## Summary Bumps `github.com/google/go-containerregistry` v0.21.5 → v0.21.7. Phase 0 of #463. v0.21.6 fixed the memory spike in `mutate.Extract` described in #120 (upstream fix: google/go-containerregistry#2190, merged as google/go-containerregistry@38d6e4087c): extraction is now refactored into a per-layer `extractLayer` function, so each layer's decompressor and HTTP response body are closed as soon as that layer is processed, instead of all being held open via deferred `Close` calls until the entire (multi-GB) extraction completes. atelet's pull path goes through `memorypullcache.Fetch` → `mutate.Extract`, so this directly caps its extract-time memory. Note this is only interim relief: #437's unbounded cache retention is untouched and is addressed by the redesign in #463. ## Changes - `go-containerregistry` v0.21.5 → v0.21.7, plus required transitive bumps: `docker/cli`, `klauspost/compress`, `golang.org/x/sync`, `golang.org/x/sys` - `go mod tidy` + `go mod vendor`; the `containerd/stargz-snapshotter/estargz` vendor tree drops out (upstream removed the estargz integration; nothing in substrate used it), along with `vbatts/tar-split` and `mitchellh/go-homedir` ## Testing - `go build ./...` passes - Full `go test ./...` passes - Verified the layer-close fix is present in the vendored `pkg/v1/mutate/mutate.go` Fixes #120 🤖 Generated with [Claude Code](https://claude.com/claude-code)
In mutate.extract, the closing of layerReader resources is deferred from inside a
forloop. As a result, the layerReaders are left open until all layers are processed, which may accumulate on images with many layers.Intorduce an inner function/closure to contain the layerReader and operations that use it, so that it can be released immediately after the current layer has been processed.