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

Đã đóng
  • Có gì không ổn?
#396 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 4 ngày

@jcogilvie đang làm issue này rồi.

Từ ngày 1/10/2026.

  • #403 của @jcogilvie — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
76/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
docker, go
Lĩnh vực
cli

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
Go
Star
22
Fork
38
Merge trung bình
3 ngày 14 giờ
Pull request đã merge (30 ngày)
46

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của crossplane/cli

Tất cả issue của crossplane/cli

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.