fix: reducing log level of failure to patch in handleErrorStatusHandler

[shawkins]

closes: #2981

[Copilot]

Pull Request Overview

This PR reduces log verbosity for status patching failures in the reconciliation error handler by changing the log level from ERROR to DEBUG in specific scenarios where the failure is expected or temporary.

• Updates log level logic to use DEBUG instead of ERROR when next reconciliation is imminent or when encountering HTTP 409 conflicts
• Adds conditional logging based on reconciliation timing and HTTP status codes
• Imports additional classes to support the new logging logic

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

[nitpick] The nested instanceof check with pattern matching creates a complex boolean expression. Consider extracting the HTTP conflict check into a separate method or variable for better readability: boolean isHttpConflict = ex instanceof KubernetesClientException kcex && kcex.getCode() == HttpURLConnection.HTTP_CONFLICT;

[Copilot]

[nitpick] Using the raw HTTP status code constant HttpURLConnection.HTTP_CONFLICT (409) may not be the most appropriate choice for Kubernetes API interactions. Consider using a Kubernetes-specific constant if available in the fabric8 client library, as HTTP 409 in Kubernetes context typically indicates resource version conflicts.

Suggested change

	&& kcex.getCode() == HttpURLConnection.HTTP_CONFLICT))) {
	&& kcex.getCode() == KubernetesClientException.CONFLICT))) {

[csviri]

Thank you for the PR.
I see your point and I'm not against this, just some points to discuss / consider:

1. if sombody (most of the time) will have logger for the framework on info level won't see any log message regarding what happened. It will just retry but there will be no info about that the conflict happened whatsoever. So the reconiliation will "silently fail". Maybe for this case just rather log a short log message without stack trace that this happened? thus:
   like:

log.info("Conflict while updating custom resource, but next reconiliation is imminent").

Would this help in your case?

2. Note that usually retry is always in place (well it is considered a bad practice if turned off), so in most the cases it will retry this error right after the conflict anyways (regardless if reconciliation is imminent (other event received meanwhile) or not).

3. another option I see is to have a dedicated logger, this where we log now the conflic we could have a dedicated logger:

private static final Logger conflictLogger = LoggerFactory.getLogger(ReconciliationDispatcher.class.getCanonicalName()+".conflict");

// omittes code


// modified log in this PR:
conflictLogger.info(
                "updateErrorStatus failed for resource: {} with version: {} for error {}",
                getUID(resource),
                getVersion(resource),
                e.getMessage(),
                ex);

Now you can change the log level of this logger to "warn" in your config you won't see these log messages, however we will be backwards compatible. (but maybe this approach is overkill)

Please let me know what do you think about these.

[shawkins]

1. Fair enough, I'll follow the same pattern from https://github.com/operator-framework/java-operator-sdk/pull/2748/files here. At worst you'll see two highly related info logs - but it should be understandable what is happening.

2. Agreed.

3. That does seem like overkill.

[shawkins]

See if this looks right. There will be three different logging behaviors, which is very similar to the other processing.

If it looks like this will be retried and is based upon a conflict, then it's a INFO message and DEBUG log of the exception.
If it looks like this will be retried and is any other reason, then it's a WARN log.
Otherwise it's an ERROR log.

[csviri]

LGTM, let's wait also for a while for @xstefank @metacosm