no rollback/uninstall strategy for CRDs

[sophsoph321]

The CRD management design proactively applies/updates CRDs before Helm install/upgrade based on CRDStrategy. However, when a Helm release is rolled back or uninstalled, no corresponding CRD cleanup or rollback logic is triggered. This creates an asymmetry: CRDs flow forward on upgrade but don't flow backward on uninstall/rollback. Wanted to understand more why this kind of behavior is acceptable?
https://github.com/fluxcd/helm-controller/blob/release/v1.4.x/internal/action/crds.go

[stefanprodan]

Wanted to understand more why this kind of behavior is acceptable?

Because Helm does it this way: CRDs + Volumes are left in the cluster at uninstall. Reason being simple, a CRD delete triggers the deletion of all custom resources, and since the controller is gone, all will be stuck in finalizers, good luck recovering from this without manually removing them. Helm itself has no means of doing what flux uninstall does.

[matheuscscp]

Docs here: https://helm.sh/docs/topics/charts/#limitations-on-crds