Behavior of ReflectorRunnable changed in version 12.0.0

[domainname]

Describe the bug

In commit 013a9b7, the behavior of ReflectorRunnable changed a little bit. A new catch block was added. See below.

java/util/src/main/java/io/kubernetes/client/informer/cache/ReflectorRunnable.java

Lines 157 to 163 in f58be10

	} catch (ApiException e) {
	if (e.getCode() == HttpURLConnection.HTTP_GONE) {
	log.info(
	"ResourceVersion {} expired, will retry w/o resourceVersion at the next time",
	getRelistResourceVersion());
	isLastSyncResourceVersionUnavailable = true;
	}

Before the commit, all exceptions are caught by this

java/util/src/main/java/io/kubernetes/client/informer/cache/ReflectorRunnable.java

Lines 164 to 166 in f58be10

	} catch (Throwable t) {
	this.exceptionHandler.accept(apiTypeClass, t);
	}

and exception handler will be invoked.

I'm not sure whether this behavior change is intended or not. It seems to me that exception handler should be invoked in the new catch block as well.

@yue9944882 BTW, what's the purpose of the exception handler? I plan to use it to do a pause when networking error (such as UnknownHostException) occurs, in order to avoid too frequent retries. Does this make sense? Well, I know that it is hard to add a custom exception handler for ReflectorRunnable at this point.

** Client Version **
12.0.0

** Kubernetes Version **
N/A

** Java Version **
Java 8

To Reproduce
Steps to reproduce the behavior:

Expected behavior

Exception handler should be invoked in the new catch block as well probably.

KubeConfig
N/A

Server (please complete the following information):

• OS: Linux
• Environment: local
• Cloud: Azure

Additional context

N/A

[brendandburns]

HTTP_GONE indicates that you are trying to watch from a resourceVersion that no longer exists. It means that the watch needs to re-list and start from the current state.

There are some more details here:
https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes

[brendandburns]

The dropping non-410 responses is a bug, and is fixed in #1617

[yue9944882]

@domainname the change is not intended, so i had #1617 to fix it. we will also cherry-picking this to 11.0.x and 12.0.x releases. the point of exception handler is providing extensibility for customizing logic for handling errors based on the exception object. e.g. in some scenarios, we hope to push notifications when the reflector is failing unexpectedly.

[domainname]

@yue9944882 @brendandburns Thank you for the fix. Do you have an ETA of 12.0.1 release?

[tony-clarke-amdocs]

@brendanburns @domainname any idea when next release might be made, waiting on a release with this PR merged.

[brendandburns]

@tony-clarke-amdocs We should definitely cut a 13.0.0 release soon. Thanks for the reminder.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[tony-clarke-amdocs]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale