stacktrace without a cause when using SharedInformerFactory without proper RBAC

[wind57]

In spring-cloud-kubernetes, we are currently using version 19.0.1 of this library.

We have some code that looks like this:

	@PostConstruct
	void inform() {
		LOG.info(() -> "Kubernetes event-based secrets change detector activated");

		namespaces.forEach(namespace -> {
			SharedIndexInformer<V1Secret> informer;
			SharedInformerFactory factory = new SharedInformerFactory(apiClient);
			factories.add(factory);

			CallGenerator callGenerator = params -> {
				try {
					return coreV1Api.listNamespacedSecretCall(namespace, null, null, null, null, null, null,
							params.resourceVersion, null, null, params.timeoutSeconds, params.watch,
							new KubernetesClientApiCallback());
				}
				catch (Exception e) {
					LOG.error("Exception in secret shared informer");
					if (e instanceof ApiException apiException) {
						LOG.error(apiException.getResponseBody());
					}
					throw new RuntimeException(e);
				}
			};

			informer = factory.sharedIndexInformerFor(callGenerator, V1Secret.class, V1SecretList.class);
			informer.addEventHandler(handler);
			informers.add(informer);
			factory.startAllRegisteredInformers();
		});
	}

This works just fine when RBAC are correctly set-up, in our case :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: watcher
rules:
  - apiGroups: ["", "extensions", "apps"]
    resources: ["configmaps", "pods", "services", "endpoints", "secrets"]
    verbs: ["get", "list", "watch"]

If I remove secrets from the resources, the API call should fail, which is expected. What is not expected is a lack of a proper message explaining why that happens. At the moment, all we get is:

listing and watching...
2024-11-28T07:58:32.154Z ERROR 1 --- [spring-cloud-kubernetes-configuration-watcher] [dels.V1Secret-1] i.k.c.informer.cache.ReflectorRunnable   : class io.kubernetes.client.openapi.models.V1Secret#Reflec
tor loop failed unexpectedly

io.kubernetes.client.openapi.ApiException: 
        at io.kubernetes.client.openapi.ApiClient.handleResponse(ApiClient.java:989) ~[client-java-api-19.0.1.jar:na]
        at io.kubernetes.client.openapi.ApiClient.execute(ApiClient.java:905) ~[client-java-api-19.0.1.jar:na]
        at io.kubernetes.client.informer.SharedInformerFactory$1.list(SharedInformerFactory.java:271) ~[client-java-19.0.1.jar:na]
        at io.kubernetes.client.informer.cache.ReflectorRunnable.run(ReflectorRunnable.java:91) ~[client-java-19.0.1.jar:na]
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:na]
        at java.base/java.util.concurrent.FutureTask.runAndReset(Unknown Source) ~[na:na]
        at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[na:na]
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[na:na]
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[na:na]
        at java.base/java.lang.Thread.run(Unknown Source) ~[na:na]

and that's it (no cause is provided), which makes it close to impossible for users to diagnose the issue.

[brendandburns]

This is printed here:

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

Line 285 in af10bf7

log.error("{}#Reflector loop failed unexpectedly", watchingApiTypeClass, t);

We can consider improving the error message here.

In the meantime, you can inject your own error handler if you want better error messages, see:

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

Line 74 in af10bf7

BiConsumer<Class<ApiType>, Throwable> exceptionHandler) {

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue 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.

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten