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

已关闭
  • 哪里不对？
#396 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 4 天内回复

@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
平均合并
3 天 14 小时
30 天内合并 PR
46

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

crossplane/cli 的其他 Issue

查看 crossplane/cli 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。