Conversation
|
Warning Review limit reached
Next review available in: 58 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughUpdated DaemonSet install and uninstall reconciliation error paths to return Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
|
@coderabbitai review |
✅ Action performedReview finished.
|
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
803f330 to
e953969
Compare
There was a problem hiding this comment.
Pull request overview
This PR updates the DaemonSet-based KataConfig reconciler to align with controller-runtime semantics: when a non-nil error is returned, the ctrl.Result is ignored and requeue timing is driven by controller-runtime’s exponential backoff. The change makes error returns explicit by returning an empty ctrl.Result{} alongside the error.
Changes:
- Replaced
return ctrl.Result{Requeue: true, RequeueAfter: ...}, errwithreturn ctrl.Result{}, errfor error paths in the DaemonSet reconcile flow. - Removes misleading explicit requeue delays in error returns (since they are not applied by controller-runtime when
err != nil).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Delete the kata install daemonset if it exists | ||
| kataInstallDaemonSet, err := r.daemonSetForKataInstall(InstallKata) | ||
| if err != nil { | ||
| r.Log.Error(err, "Failed getting DaemonSet for Kata installation") | ||
| return ctrl.Result{Requeue: true, RequeueAfter: 15 * time.Second}, err | ||
| return ctrl.Result{}, err |
e953969 to
0115b42
Compare
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: openshift#2410 (comment)
Fixes: openshift#2433
See also: openshift#2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
controller-runtime ignores the Result when err != nil, using exponential
backoff instead. Returning both a RequeueAfter delay and an error is
misleading - the delay is never applied.
Changed all error returns from:
return ctrl.Result{Requeue: true, RequeueAfter: duration}, err
to:
return ctrl.Result{}, err
This makes the error handling behavior explicit and matches controller-runtime
semantics. The controller will still requeue, but using its default exponential
backoff mechanism.
Addresses: #2410 (comment)
Fixes: #2433
See also: #2434 (same fix on `devel`)
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Assisted-by: Claude Sonnet 4.5
(cherry picked from commit d7f8e97)
Signed-off-by: Julien Ropé <jrope@redhat.com>
0115b42 to
bd3d10c
Compare
|
Closed since this was merged elsewhere |
|
@c3d: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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. I understand the commands that are listed here. |
controller-runtime ignores the Result when
err != nil, using exponential backoff instead. Returning both aRequeueAfterdelay and an error is misleading - the delay is never applied.Changed all error returns from:
to:
This makes the error handling behavior explicit and matches controller-runtime semantics. The controller will still requeue, but using its default exponential backoff mechanism.
Found while addressing code review comments on PR #2410
Fixes: #2433
Assisted-By: Claude Sonnet 4.5