An error return that turned a terminal failure into a busy loop.
Kurze Antwort
When a delete pipeline for a Kratix Promise or resource request failed, the controller returned an error on every reconcile. Controller-runtime requeues on error, so the object was reconciled over and over without the pipeline ever rerunning. The fix treats a failed delete pipeline as settled: it still records the failure condition and event, logs it, and returns without an error. Recovery happens through a manual reconciliation, a pipeline change, or the existing retryAfter mechanism. It was merged as PR #968 and closed issue #102.
The problem
Kratix is an open-source framework for building internal platforms on Kubernetes. Issue #102, opened in April 2024, flagged the loop and its cost: "if many pipelines fail at once on the same cluster: the continual requeuing may end up using a chunk of the resources." The issue was framed as an open question: "It's unclear what the right behaviour is here (since returning an error will also requeue), so this ticket is a placeholder/RFC!"
The fix
The same pattern in both the Promise and dynamic resource-request controllers:
if errors.Is(err, workflow.ErrDeletePipelineFailed) {
logging.Info(o.logger, "resource delete workflow failed; waiting for a manual reconciliation")
return ctrl.Result{}, nil
}Existing tests that expected the error were updated, and new cases assert that a further reconcile neither errors nor requeues.
By the numbers
- Repository: syntasso/kratix, 785 stars (Nov 3, 2026), Go, Apache-2.0
- Files changed: 4
- Lines: +24 / -5
- Commits: 4 (1 from the PR author, 3 maintainer merges of
main) - Opened: Oct 10, 2026. Merged: Oct 20, 2026. Time to merge: 10 days, 1 hour
- Review: merged by a maintainer after the CLA was signed
How the review went
The maintainer wrote "Thanks for your contribution @Roshan931! If you could sign the CLA, we can get this merged!" Once it was signed, they merged it with "Thank you!"
FAQ
How do I retry a failed delete pipeline now?
Per the PR description, through a manual reconciliation or a pipeline change, which restarts the workflow, or through the existing retryAfter workflow control.
Where can I read more?
See the pull request and the original issue.
Das Ziel
In a controller, returning an error means "try again". When trying again can't help, record the failure and wait for a signal that something changed.
