🐛 set Progressing condition to False on successful reconciliation#2810
🐛 set Progressing condition to False on successful reconciliation#2810vdurgam10 wants to merge 2 commits into
Conversation
The Progressing condition on ClusterExtension resources was always set to status: True with reason: Succeeded after a successful reconciliation. This is semantically incorrect — Progressing=True means "still working," which contradicts the Succeeded reason and the "Desired state reached" message. This fix changes the default Progressing status to ConditionFalse (done progressing) and only sets ConditionTrue when there is an active non-terminal error causing retries. Terminal errors correctly remain ConditionFalse with reason Blocked. Before: Installed=True Progressing=True reason=Succeeded "Desired state reached" After: Installed=True Progressing=False reason=Succeeded "Desired state reached" Signed-off-by: Venkatesh Durgam <vdurgam@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Pull request overview
This PR corrects ClusterExtension condition semantics so Progressing reflects “work still in progress” rather than being set to True after a successful reconciliation, aligning status reporting with standard Kubernetes condition meaning.
Changes:
- Default
ProgressingtoFalsewith reasonSucceededand message “Desired state reached” when reconciliation succeeds. - Set
Progressing=Trueonly when reconciliation returns a non-terminal error (retrying), while keeping terminal errorsProgressing=Falsewith an appropriate blocked reason. - Update unit and controller tests to assert the corrected
Progressingstatus on successful installs/fallback scenarios.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| internal/operator-controller/controllers/common_controller.go | Adjusts setStatusProgressing default condition status to False on success and True on non-terminal errors. |
| internal/operator-controller/controllers/common_controller_test.go | Updates unit test expectations for Progressing on success and error scenarios. |
| internal/operator-controller/controllers/clusterextension_controller_test.go | Updates integration/controller tests to expect Progressing=False after successful reconciliation paths. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| }{ | ||
| { | ||
| name: "non-nil ClusterExtension, nil error, Progressing condition has status True with reason Success", | ||
| name: "non-nil ClusterExtension, nil error, Progressing condition has status False with reason Success", |
Update ClusterExtension e2e assertions to match the corrected Progressing condition semantics. ClusterObjectSet assertions are unchanged as they use a separate controller. Signed-off-by: Venkatesh Durgam <vdurgam@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Summary
Progressingcondition onClusterExtensionresources was incorrectly set tostatus: Truewithreason: Succeededafter successful reconciliation. This is semantically wrong —Progressing=Truemeans "still working," which contradicts theSucceededreason and "Desired state reached" message.Progressingstatus toConditionFalse(done progressing) and only setsConditionTruewhen there is an active non-terminal error causing retries. Terminal errors correctly remainConditionFalsewith reasonBlocked.Before
After
Condition semantics
FalseSucceededTrueRetryingFalseBlocked/ specific reasonTest plan
TestSetStatusProgressing— all 8 sub-tests)TestClusterExtensionInstallationSucceeds,TestResolutionFallbackToInstalledBundle)Made with Cursor