fix: patch operator-owned status instead of replacing it - #277
Open
stigglor wants to merge 1 commit into
Open
Conversation
A reconcile reads its CR, then holds it through pipeline collection, config build, configcheck (300s by default) and the workload write before it sets status. By then the resourceVersion is routinely stale, so Status().Update fails with "the object has been modified" and the whole configcheck runs again on the requeue. Cached reads widen the window: a reconcile triggered right after a status write can read the version from before it, and the pipeline controller pushes an event per agent from each of its 20 concurrent reconciles, so back to back reconciles of one CR are normal. Nothing but this operator writes these status subresources, so optimistic concurrency buys nothing here. The status setters now send a merge patch built against the object as read, carrying no resourceVersion and only the status diff, so a stale object can neither lose the write nor clobber a concurrent edit to spec or metadata. Pipelines pass that base in from the reconcile, since the role is set into status while configcheck runs and has to stay in the patch. The success paths force reason into the patch base. It is omitempty, so a base read before an earlier failure was recorded would emit no reason key and leave the old text sitting next to configCheckResult true. Closes kaasops#174
stigglor
force-pushed
the
fix/status-update-conflicts
branch
from
August 11, 2026 08:11
6e2cb46 to
a86bf38
Compare
stigglor
marked this pull request as ready for review
August 11, 2026 08:40
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A reconcile reads its CR, then holds it through pipeline collection, config
build, configcheck (300s by default) and the workload write before it sets
status. By then the resourceVersion is routinely stale, so Status().Update
fails with "the object has been modified" and the whole configcheck runs again
on the requeue. Cached reads widen the window: a reconcile triggered right
after a status write can read the version from before it, and the pipeline
controller pushes an event per agent from each of its 20 concurrent reconciles,
so back to back reconciles of one CR are normal.
Nothing but this operator writes these status subresources, so optimistic
concurrency buys nothing here. The status setters now send a merge patch built
against the object as read, carrying no resourceVersion and only the status
diff, so a stale object can neither lose the write nor clobber a concurrent
edit to spec or metadata. Pipelines pass that base in from the reconcile, since
the role is set into status while configcheck runs and has to stay in the patch.
The success paths force reason into the patch base. It is omitempty, so a base
read before an earlier failure was recorded would emit no reason key and leave
the old text sitting next to configCheckResult true.
Closes #174