🐛 Fix regression in Apply typed error handling#3515
Conversation
a30487e to
729377b
Compare
729377b to
a51b34c
Compare
a51b34c to
41f79d1
Compare
|
/cherrypick release-0.24 |
|
@alvaroaleman: once the present PR merges, I will cherry-pick it on top of DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Signed-off-by: Erik Godding Boye <egboye@gmail.com>
41f79d1 to
a500bff
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alvaroaleman, erikgb The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
LGTM label has been added. DetailsGit tree hash: 83924df9874c60a1dbe24c5d945843955c99816f |
|
@alvaroaleman: new pull request created: #3516 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
When attempting to upgrade K8s dependencies in multiple operators, I noticed what seems to be a regression in the error handling for the Apply method in the controller-runtime client. Sadly, only one of the operators I've been having issues with is open source, but the problem can be observed in the failing CI of statnett/image-scanner-operator#1729. This operator contains compensating logic for the
RequestEntityTooLargeerror (HTTP status 413), which is broken after upgrading K8s deps (including controller-runtime).In one of our closed-source operators, I observe a similar issue, which is likely to be related. There we have compensating logic if trying to modify an immutable field. The tests are failing for the upgrade PR with the following logged inside the operator:
{"level":"error","ts":"2026-05-04T08:50:50Z","msg":"Reconciler error","controller":"application","controllerGroup":"stas.statnett.no","controllerKind":"Application","Application":{"name":"v1beta2-immutable-field","namespace":"application-operator"},"namespace":"application-operator","name":"v1beta2-immutable-field","reconcileID":"45487740-546a-427e-a4d4-f826bf4042eb","error":"the server rejected our request due to an error in our request (patch deployments.apps v1beta2-immutable-field)","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.24.0/pkg/internal/controller/controller.go:494\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.24.0/pkg/internal/controller/controller.go:437\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Start.func1.1\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.24.0/pkg/internal/controller/controller.go:312"}I believe the regression was introduced in #3475, which represents a good improvement/feature. But I think the error handling was dramatically changed by the PR.