render: docker engine discards the network-removal error, so crossplane-render-* networks leak silently
Maintainer thường phản hồi trong vòng 2 ngày
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- docker, go
- Lĩnh vực
- infrastructure
Hướng nghiên cứu
Start with the cleanup returned by Engine.Setup in cmd/crossplane/render/engine_docker.go, then trace its deferred use in xr/cmd.go and op/cmd.go around StopFunctionRuntimes. Reproduce the start-failure or slow-stop cases from #396 and #397, and verify that a failed network removal becomes visible to the caller or command instead of being discarded.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
What happened?
The temporary crossplane-render-* network the docker render engine creates is left behind whenever a
container is still attached to it at cleanup time, and nothing reports the failure.
The cleanup returned by the docker engine's Setup discards its error
(engine_docker.go L106-L108):
cleanup := func() { //nolint:contextcheck // Detached context for cleanup.
_ = removeRenderNetwork(context.Background(), networkID)
}
In xr/cmd.go and op/cmd.go this cleanup is deferred before StopFunctionRuntimes, so it runs last,
which is the right order. But if any container was leaked (#396, #397), it is still attached to the
network, NetworkRemove fails because the network has active endpoints, and the error is dropped. The
cleanup func signature (func()) means callers can't learn about it either.
Expected: a network-removal failure is reported (returned to, or at least logged visibly for, the caller),
so it doesn't vanish silently.
This affects library consumers that call Engine.Setup as well as the render commands.
How can we reproduce it?
Run either the start-failure reproduction from #396 or the slow-stop reproduction from #397. The run's network is still
there afterwards:
$ docker network ls --filter name=crossplane-render- --format '{{.CreatedAt}} {{.Name}}'
2026-09-30 18:55:29 -0400 EDT crossplane-render-b2rvl4jh
Once the leaked containers are removed by hand, docker network rm on the same network succeeds.
In our testing, every run that leaked a container also leaked its network (the start-failure run, all 7
slow-stop trials, and both interrupted runs from #400); each network's creation time matched its run.
Runs where every container was removed left no network. That points to the attached containers as what
makes network removal fail.
Possible fixes:
- Return or log the
removeRenderNetworkerror instead of discarding it. Changing theSetupcleanup's type
fromfunc()tofunc() errorwould let callers handle it, though that changes theEngineinterface. - Optionally, before removing the network, disconnect or force-remove any render-owned containers still
attached to it. That would be much safer once render-created resources are labelled (#401), because a
user-supplied--crossplane-docker-networkmay have unrelated containers on it.
What environment did it happen in?
- Crossplane CLI version: built from
main@29316fea54f2ede9d2c039d9c54f0c29cbad4b65 - Platform (e.g., linux/amd64): darwin/arm64, Docker Engine 29.5.3 (Rancher Desktop)
- Crossplane version (if applicable): render engine image
xpkg.crossplane.io/crossplane/crossplane:stable
- Ngôn ngữ chính
- Go
- Star
- 19
- Fork
- 33
- Merge trung bình
- 3 ngày 4 giờ
- Pull request đã merge (30 ngày)
- 40
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của crossplane/cli
-
`credsStore` in docker config causes unit test failuresCó thể đã có người làm @sujeito-operator đã nhận 47 ngày trước. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
crossplane/cli#282 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
render: label the Docker containers and networks render createsCó thể đã có người làm @jcogilvie đã nhận 4 ngày trước. Đang mởenhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
crossplane/cli#401 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
render: interrupting with Ctrl+C (SIGINT/SIGTERM) leaks Function containers, the render container, and the networkCó thể đã có người làm @jcogilvie đã nhận 4 ngày trước. Đang mởbug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
crossplane/cli#400 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
render: Function cleanup failures are invisible without --verboseCó thể đã có người làm @jcogilvie đã nhận 4 ngày trước. Đang mởbug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 70/100
crossplane/cli#399 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
render: stopping Function runtimes aborts on the first error, and the shared 5s budget skips container removalCó thể đã có người làm @jcogilvie đã nhận 4 ngày trước. Đang mởbug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 66/100
crossplane/cli#397 ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của crossplane/cli
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
txn2/mcp-data-platform#2030 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area/tests theme/ci-dx
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày
-
ai-inspected
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: e2e script flag parsing is brokenCó thể đã có người làm @ericcurtin đã nhận hôm nay. Đang mởarea/dev-infra area/tests kind/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
agent-substrate/substrate#2217 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: multi-arch `vgpu-device-manager` image digest not pinned in OLM bundleCó thể đã có người làm @MrBeldum đã nhận hôm nay. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
NVIDIA/gpu-operator#3012 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày