Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

render: docker engine discards the network-removal error, so crossplane-render-* networks leak silently

オープン
  • 何か問題がありますか？
#398 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

@jcogilvie がすでに取り組んでいます。

2026年10月1日 から。

  • #405 @jcogilvie による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
docker, go
領域
infrastructure

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

bug
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 removeRenderNetwork error instead of discarding it. Changing the Setup cleanup's type
    from func() to func() error would let callers handle it, though that changes the Engine interface.
  • 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-network may 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
主要言語
Go
スター
20
フォーク
33
平均マージ
3日 10時間
マージ済み PR（30日）
24

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

crossplane/cli のほかの issue

crossplane/cli の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。