render: StartFunctionRuntimes leaks already-started Function containers when a later Function fails to start

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

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

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

2026年10月1日 から。

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

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
76/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
docker, go
領域
cli

調査の方向性

Start in cmd/crossplane/render/render.go at StartFunctionRuntimes, then inspect the error handling in xr/cmd.go and op/cmd.go. Reproduce with the supplied xr.yaml, composition.yaml, and functions.yaml, and verify that a later startup failure stops earlier runtimes and removes the attached network instead of leaving containers running.

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

説明

bug
What happened?

When one Function fails to start, every Function started before it is left running and nothing ever stops
it.

StartFunctionRuntimes
starts Functions in order. If Function N fails (for example its image can't be pulled), it returns
nil, err. Functions 1..N-1 are already running, but their RuntimeContexts are dropped with the partial
FunctionAddresses, so no caller can stop them. In xr/cmd.go and op/cmd.go the
defer render.StopFunctionRuntimes(...) comes after the error check, so it is never registered.

Expected: if StartFunctionRuntimes returns an error, any runtime it already started has been stopped
according to its cleanup policy — or the partial result is returned so the caller can stop it.

This affects library consumers as well as the render commands: any caller of StartFunctionRuntimes has
the same gap.

How can we reproduce it?

xr.yaml:

apiVersion: example.org/v1
kind: XThing
metadata:
  name: test-xr
spec:
  coolField: hello

composition.yaml — any pipeline referencing the three Functions below, e.g.:

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: xthings.example.org
spec:
  compositeTypeRef: {apiVersion: example.org/v1, kind: XThing}
  mode: Pipeline
  pipeline:
  - step: templating
    functionRef: {name: function-go-templating}
    input:
      apiVersion: gotemplating.fn.crossplane.io/v1beta1
      kind: GoTemplate
      source: Inline
      inline:
        template: |
          apiVersion: nop.crossplane.io/v1alpha1
          kind: NopResource
          metadata:
            annotations: {gotemplating.fn.crossplane.io/composition-resource-name: nop}
          spec: {forProvider: {}}
  - step: dummy
    functionRef: {name: function-dummy}
    input: {apiVersion: dummy.fn.crossplane.io/v1beta1, kind: Response, response: {}}
  - step: auto-ready
    functionRef: {name: function-auto-ready}

functions.yaml — the last Function's tag has no manifest, so its pull fails:

apiVersion: pkg.crossplane.io/v1
kind: Function
metadata: {name: function-go-templating}
spec: {package: xpkg.crossplane.io/crossplane-contrib/function-go-templating:v0.11.0}
---
apiVersion: pkg.crossplane.io/v1
kind: Function
metadata: {name: function-dummy}
spec: {package: xpkg.crossplane.io/crossplane-contrib/function-dummy:v0.4.1}
---
apiVersion: pkg.crossplane.io/v1
kind: Function
metadata: {name: function-auto-ready}
spec: {package: xpkg.crossplane.io/crossplane-contrib/function-auto-ready:v0.1.2}

$ crossplane render xr.yaml composition.yaml functions.yaml
crossplane: error: cannot start function runtimes: cannot start Function "function-auto-ready": cannot pull Docker image "xpkg.crossplane.io/crossplane-contrib/function-auto-ready:v0.1.2": Error response from daemon: manifest unknown
$ docker ps --format '{{.Names}} {{.Image}} {{.Status}}' | grep function-
suspicious_newton xpkg.crossplane.io/crossplane-contrib/function-dummy:v0.4.1 Up 9 seconds
distracted_mestorf xpkg.crossplane.io/crossplane-contrib/function-go-templating:v0.11.0 Up 13 seconds

Both containers use the default cleanup policy (Remove) and stay running indefinitely. The run's
crossplane-render-* network is also left behind, because its removal fails while these containers are
attached and the error is discarded (#398).

Possible fix: on error, stop the runtimes started so far before returning (e.g. build the
FunctionAddresses as you go and call Stop on it in the error path), or return the partial
*FunctionAddresses alongside the error and document that callers must stop 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
スター
22
フォーク
38
平均マージ
5日 20時間
マージ済み PR（30日）
34

環境構築

はじめの一歩

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

crossplane/cli のほかの issue

crossplane/cli の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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