This is a backport issue for #5261, automatically created via GitHub Actions workflow initiated by @kkaempf
Original issue body:
Is there an existing issue for this?
Current Behavior
When a fleet.yaml sets an explicit name: field longer than 53 characters without also setting helm.releaseName, the agent's garbage collector periodically uninstalls the corresponding helm release, even though it is valid and actively managed. Fleet immediately redeploys it, and the GC uninstalls it again — indefinitely.
The agent logs the following repeatedly:
{"level":"info","logger":"bundledeployment.garbage-collect",
"msg":"Deleting unknown bundle ID, helm uninstall",
"bundleID":"",
"release":"/-",
"expectedRelease":"/"}
Expected Behavior
The GC recognises the release as belonging to the bundle deployment and leaves it untouched.
Steps To Reproduce
See https://github.com/nilsalex/fleet-gc-bug-repro for a minimal reproduction with instructions.
Environment
- Architecture: amd64
- Fleet Version: v0.14.3
- Cluster: reproduced on k3d and EKS
Logs
{"level":"info","logger":"bundledeployment.garbage-collect",
"msg":"Deleting unknown bundle ID, helm uninstall",
"bundleID":"repro-bundle-name-that-exceeds-the-53-char-helm-limit-x",
"release":"default/repro-bundle-name-that-exceeds-the-53-char-helm-98fdb",
"expectedRelease":"default/repro-bundle-name-that-exceeds-the-53-char-helm-limit-x"}Anything else?
Root cause
The helm release name is derived from bd.Name via names.HelmReleaseName() in getOpts() (internal/helmdeployer/deployer.go), which truncates names longer than 53 characters and appends a 5-character hash. The GC's releaseKey() function (internal/cmd/agent/deployer/cleanup/cleanup.go) computes the expected release name using bd.Name directly, without applying the same truncation. The two values diverge whenever bd.Name exceeds 53 characters.
bd.Name exceeds 53 characters when a fleet.yaml sets an explicit name: field longer than 53 characters — the value is used raw as the Bundle and BundleDeployment name, bypassing the sanitization that auto-derived names go through. Setting helm.releaseName explicitly avoids the bug, since both getOpts() and releaseKey() use it directly without truncation.
This is a backport issue for #5261, automatically created via GitHub Actions workflow initiated by @kkaempf
Original issue body:
Is there an existing issue for this?
Current Behavior
When a fleet.yaml sets an explicit name: field longer than 53 characters without also setting helm.releaseName, the agent's garbage collector periodically uninstalls the corresponding helm release, even though it is valid and actively managed. Fleet immediately redeploys it, and the GC uninstalls it again — indefinitely.
The agent logs the following repeatedly:
{"level":"info","logger":"bundledeployment.garbage-collect",
"msg":"Deleting unknown bundle ID, helm uninstall",
"bundleID":"",
"release":"/-",
"expectedRelease":"/"}
Expected Behavior
The GC recognises the release as belonging to the bundle deployment and leaves it untouched.
Steps To Reproduce
See https://github.com/nilsalex/fleet-gc-bug-repro for a minimal reproduction with instructions.
Environment
Logs
{"level":"info","logger":"bundledeployment.garbage-collect", "msg":"Deleting unknown bundle ID, helm uninstall", "bundleID":"repro-bundle-name-that-exceeds-the-53-char-helm-limit-x", "release":"default/repro-bundle-name-that-exceeds-the-53-char-helm-98fdb", "expectedRelease":"default/repro-bundle-name-that-exceeds-the-53-char-helm-limit-x"}Anything else?
Root cause
The helm release name is derived from bd.Name via names.HelmReleaseName() in getOpts() (internal/helmdeployer/deployer.go), which truncates names longer than 53 characters and appends a 5-character hash. The GC's releaseKey() function (internal/cmd/agent/deployer/cleanup/cleanup.go) computes the expected release name using bd.Name directly, without applying the same truncation. The two values diverge whenever bd.Name exceeds 53 characters.
bd.Name exceeds 53 characters when a fleet.yaml sets an explicit name: field longer than 53 characters — the value is used raw as the Bundle and BundleDeployment name, bypassing the sanitization that auto-derived names go through. Setting helm.releaseName explicitly avoids the bug, since both getOpts() and releaseKey() use it directly without truncation.