Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

genreconciler: successful finalization breaks status updates #2519

Open
mattmoor opened this issue May 17, 2022 · 4 comments
Open

genreconciler: successful finalization breaks status updates #2519

mattmoor opened this issue May 17, 2022 · 4 comments
Labels
area/API kind/bug Categorizes issue or PR as related to a bug. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@mattmoor
Copy link
Member

mattmoor commented May 17, 2022

/area API
/kind bug

This is a largely superficial issue, which I only noticed because of some unit testing I was writing and trying to explain this odd behavior.

Expected Behavior

If in FinalizeKind a resource is marked Ready, and nil is returned, then we see both updates (path for finalizer, update status for Ready).

Actual Behavior

Instead the finalizer is removed and the status is NOT updated.

The bug

Using Deployment as an example... If in FinalizeKind we update status and return nil then we will call through here:

if resource, err = r.clearFinalizer(ctx, resource, reconcileEvent); err != nil {
return fmt.Errorf("failed to clear finalizers: %w", err)
}

This function uses the input resource (with the updated status) to access the finalizers, find ours and remove it:

resource.Finalizers = finalizers.List()
// Synchronize the finalizers filtered by r.finalizerName.
return r.updateFinalizersFiltered(ctx, resource)

The resource we pass in is used to compute a PATCH on the finalizers specifically:

mergePatch := map[string]interface{}{
"metadata": map[string]interface{}{
"finalizers": finalizers,
"resourceVersion": existing.ResourceVersion,
},
}

However, any other mutations (e.g. our status update) are ignored here. This is a problem because the resource that is returned by this function is the updated copy that is returned by the PATCH which does not have our status update reflected:

updated, err := patcher.Patch(ctx, resourceName, types.MergePatchType, patch, metav1.PatchOptions{})
if err != nil {
r.Recorder.Eventf(existing, v1.EventTypeWarning, "FinalizerUpdateFailed",
"Failed to update finalizers for %q: %v", resourceName, err)
} else {
r.Recorder.Eventf(updated, v1.EventTypeNormal, "FinalizerUpdate",
"Updated %q finalizers", resource.GetName())
}
return updated, err

@knative-prow knative-prow bot added area/API kind/bug Categorizes issue or PR as related to a bug. labels May 17, 2022
@mattmoor
Copy link
Member Author

I think the best "fix" for this would be to not return updated directly, but to reflect its resourceVersion change back to resource and return that so the status is preserved.

@mattmoor
Copy link
Member Author

cc @dprotaso @n3wscott

@github-actions
Copy link
Contributor

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 16, 2022
@psschwei
Copy link
Contributor

/lifecycle frozen

@knative-prow knative-prow bot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Aug 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/API kind/bug Categorizes issue or PR as related to a bug. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

2 participants