Skip to content

Remove ContainsFinalizer check before adding it ✨🐛 #4789

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

matrus2
Copy link

@matrus2 matrus2 commented Apr 25, 2025

fix: #4564

This pull request refactors the logic for adding finalizers in multiple reconciler implementations to simplify the code and improve readability. The changes replace the use of controllerutil.ContainsFinalizer checks with a more concise pattern that directly checks the result of controllerutil.AddFinalizer.

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Apr 25, 2025
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: matrus2
Once this PR has been reviewed and has the lgtm label, please assign varshaprasad96 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

}

if added := controllerutil.AddFinalizer(busybox, busyboxFinalizer); added {
log.Info("Finalizer added for Busybox")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for the suggestion and for taking the time to improve the code! 🙏

The reason for keeping the original implementation as it is, is because:

Separation of concerns:
We first check if the finalizer is already present using ContainsFinalizer, and only attempt to add it if necessary. This makes the logic clear and avoids unnecessary operations.

Efficient error handling:
By explicitly checking first, we can log and manage errors more precisely at each step, which makes debugging and monitoring easier.

Avoid unnecessary API server writes:
Updating the resource only when a change is needed helps reduce API server load, avoids unnecessary reconciliation retries, and keeps the controller efficient.

Even though AddFinalizer internally checks, doing the explicit check first improves clarity, and bring the above benefits which seems more aligned.

For these reasons, I think it might be better to keep the original implementation as it is.

Thanks again for your contribution and for sparking this valuable discussion! 🌟

Copy link
Member

@camilamacedo86 camilamacedo86 Apr 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/hold

If you do not mind, I think we should close this one as not accepted.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the quick and thorough review
I agree that using ContainsFinalizer and AddFinalizer together improves readability. However, I still believe the original code block is misleading and can be improved. It appears to contain dead code within the conditional block:

		if ok := controllerutil.AddFinalizer({{ lower .Resource.Kind }}, {{ lower .Resource.Kind }}Finalizer); !ok {
			err = fmt.Errorf("finalizer for {{ .Resource.Kind }} was not added")
			log.Error(err, "Failed to add finalizer for {{ .Resource.Kind }}")
			return ctrl.Result{}, err
		}

Since the presence of the finalizer is checked before this block (by ContainsFinalizer), the condition where AddFinalizer returns false (and thus the error logging) will never be reached. Examining the implementation of AddFinalizer confirms this, as it only appends the finalizer and returns true if it wasn't already present.

My proposal aims for a more precise approach:

	if !controllerutil.ContainsFinalizer(memcached, memcachedFinalizer) {
		log.Info("Adding Finalizer for Memcached")
		controllerutil.AddFinalizer(memcached, memcachedFinalizer)
		if err = r.Update(ctx, memcached); err != nil {
			log.Error(err, "Failed to update custom resource to add finalizer")
			return ctrl.Result{}, err
		}
	}

This revised code explicitly checks for the finalizer's absence, logs the intention to add it, performs the addition, and then handles potential errors during the update operation.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@camilamacedo86 Would you agree with this approach?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @matrus2

Thank you for looking into that.
Your observation seems to be accurate, and your proposal seems to solve it well. 👍

Could you please update this PR with the proposal?
Also, please ensure that you squash the commits for we have a good git history.

Thank you a lot 🥇

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cronjob example - add fianlizer
3 participants