THREESCALE-14654 Fix status reconciler requeue logic#1177
Conversation
|
/retest |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1177 +/- ##
==========================================
+ Coverage 43.16% 43.98% +0.82%
==========================================
Files 203 204 +1
Lines 20885 20927 +42
==========================================
+ Hits 9015 9205 +190
+ Misses 11056 10920 -136
+ Partials 814 802 -12
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
5086f39 to
bf7312e
Compare
| if equalStatus { | ||
| s.logger.V(1).Info("Status was not updated") | ||
| if !newAvailable { | ||
| return reconcile.Result{RequeueAfter: 30 * time.Second}, nil |
There was a problem hiding this comment.
As discussed, we now return reconcile.Result{RequeueAfter: 30 * time.Second}, nil, but inside apimanager_controller.go we only check Requeue, so the result is ignored.
if statusResult.Requeue {
logger.Info("Reconciling not finished. Requeueing.")
return statusResult, nil
}
…us write Two issues in the previous requeue logic: 1. The guard `equalStatus && newAvailable` caused the unavailable-but-equal case to fall through to a status write even when nothing had changed, producing a no-op write on every reconcile while the instance remained unavailable. The new `if equalStatus` guard short-circuits both the available and unavailable steady states, avoiding the unnecessary write. 2. Both unavailable return paths used `Requeue: true` (immediate requeue), which causes tight-loop reconciliation against an instance that is still unavailable. Switching to `RequeueAfter: 30s` gives components time to recover between checks and avoids extending backoff counter. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
bf7312e to
9a9dee8
Compare
|
/retest |
1 similar comment
|
/retest |
| return specResult, nil | ||
| } | ||
|
|
||
| if statusResult.Requeue { |
There was a problem hiding this comment.
We only check the last one? reconcileAPIManagerStatus is called more than once
| s.logger.V(1).Info("Status is different") | ||
| s.apimanagerResource.Status = *newStatus | ||
| if err := s.Client().Status().Update(s.Context(), s.apimanagerResource); err != nil { | ||
| return reconcile.Result{}, fmt.Errorf("failed to update status: %w", err) |
There was a problem hiding this comment.
We now ignore the Conflict error?
|
/retest |
|
@urbanikb: The following test failed, say
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. |
Fixes https://issues.redhat.com/browse/THREESCALE-14654
Summary
equalStatus && newAvailableguard: the unavailable-but-equal case fell through to a no-op status write on every reconcile. Changed toif equalStatuswhich short-circuits both available and unavailable steady states.Requeue: true(immediate tight-loop) toRequeueAfter: 30s, giving components time to recover between checks and avoiding extending the backoff counter.Test plan
go test ./controllers/apps/... -run TestAPIManagerStatusReconcilerTestAPIManagerStatusReconciler_Reconcile_requeueAfterWhenUnavailableverifies RequeueAfter is non-zero on True→False transitionManual testing setup
Tested manually with following setup:
After system provisions and stabilises, delete one of the route, to induce "Available: false", observe the logs for some time - the reconcile was triggered every 30s.
🤖 Co-authored with Claude Code