apple / apple/container-builder-shim

[Bug]: Concurrent builds share one context cache name and delete each other's tar

Open
#92 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
135
Forks
34
Avg merge
1h 17m
Merged PRs (30d)
1

Description

### I have done the following

- [x] I have searched the existing issues
- [x] If possible, I've reproduced the issue using the 'main' branch of this project

### Steps to reproduce

Run several builds at once on one machine. The simplest case is builds that carry no build context at all, which is common in CI and when iterating locally:

```sh
for i in 1 2 3 4 5 6 7 8; do container build -t probe:$i -f Containerfile . & done; wait
```

The race is in `pkg/fileutils/tarxfer.go`, and it reproduces deterministically as a unit test. The receive path streams the context into a tar named for the content it holds, unpacks it to a directory of the same name, and removes the tar on the way out. Builds carrying identical context, and builds carrying no context, all derive the same name.

### Current behavior

Two receives that resolve to the same cache name use the same tar path and the same unpack directory. One receive removes the tar while another is still writing to it, and the build that loses the race fails because the file it just created no longer exists.

### Expected behavior

Concurrent builds do not interfere. A build that finds the cache already populated by another build should use it, since the entry is keyed by content and therefore identical.

### Environment

- OS: macOS 26.6
- Go: go1.25.5 (module), reproduced with go1.27.0
- Xcode: 26.x

### Relevant log output

```shell
--- FAIL: TestReceiver_Receive_ConcurrentSameContent
tarxfer_test.go:261: receiver 7: unexpected EOF
FAIL github.com/apple/container-builder-shim/pkg/fileutils
```

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Contributor guide

Open the contributing guide

Research direction

Start in pkg/fileutils/tarxfer.go and read the concurrent receive test in tarxfer_test.go, especially the failure at line 261. Reproduce with TestReceiver_Receive_ConcurrentSameContent and inspect how identical or empty contexts derive tar and unpack paths. Done means concurrent receives no longer delete or overwrite each other's files and the test passes.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
build-system
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
78/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.