Skip to content

Commit 392c365

Browse files
authored
fix: remove deprecated api (#842)
1 parent f408a14 commit 392c365

File tree

2 files changed

+7
-9
lines changed

2 files changed

+7
-9
lines changed

operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/ReconciliationDispatcher.java

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -335,7 +335,7 @@ public R updateStatus(R resource) {
335335
return resourceOperation
336336
.inNamespace(resource.getMetadata().getNamespace())
337337
.withName(getName(resource))
338-
.updateStatus(resource);
338+
.replaceStatus(resource);
339339
}
340340

341341
public R replaceWithLock(R resource) {

operator-framework/src/test/java/io/javaoperatorsdk/operator/SubResourceUpdateIT.java

Lines changed: 6 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -70,15 +70,13 @@ void ifNoFinalizerPresentFirstAddsTheFinalizerThenExecutesControllerAgain() {
7070
}
7171

7272
/**
73-
* Not that here status sub-resource update will fail on optimistic locking. This solves a tricky
74-
* situation: If this would not happen (no optimistic locking on status sub-resource) we could
75-
* receive and store an event while processing the controller method. But this event would always
76-
* fail since its resource version is outdated already.
73+
* The update status actually does optimistic locking in the background but fabric8 client retries
74+
* it with an up-to-date resource version.
7775
*/
7876
@Test
7977
void updateCustomResourceAfterSubResourceChange() {
8078
SubResourceTestCustomResource resource = createTestCustomResource("1");
81-
operator.create(SubResourceTestCustomResource.class, resource);
79+
resource = operator.create(SubResourceTestCustomResource.class, resource);
8280

8381
// waits for the resource to start processing
8482
waitXms(EVENT_RECEIVE_WAIT);
@@ -89,9 +87,9 @@ void updateCustomResourceAfterSubResourceChange() {
8987

9088
// wait for sure, there are no more events
9189
waitXms(WAIT_AFTER_EXECUTION);
92-
// there is no event on status update processed
93-
assertThat(TestUtils.getNumberOfExecutions(operator))
94-
.isEqualTo(3);
90+
// note that both is valid, since after the update of the status the event receive lags,
91+
// that will result in a third execution
92+
assertThat(TestUtils.getNumberOfExecutions(operator)).isBetween(2, 3);
9593
}
9694

9795
void awaitStatusUpdated(String name) {

0 commit comments

Comments
 (0)