Error Logs of ReflectorRunnable caused by too 'old resource version'

[FlorianBuchegger]

Describe the bug
We are using the SharedIndexInformer and notice error logs appearing from time to time, f.e.:

2021-03-11 03:35:41.406 UTC ERROR 76235 --- [.V1Deployment-1] i.k.c.informer.cache.ReflectorRunnable   : class io.kubernetes.client.openapi.models.V1Deployment#Reflector loop failed unexpectedly
java.lang.RuntimeException: got ERROR event and its status: class V1Status {
    apiVersion: v1
    code: 410
    details: null
    kind: Status
    message: too old resource version: 8886375 (8888886)
    metadata: class V1ListMeta {
        _continue: null
        remainingItemCount: null
        resourceVersion: null
        selfLink: null
    }
    reason: Expired
    status: Failure
}
	at io.kubernetes.client.informer.cache.ReflectorRunnable.watchHandler(ReflectorRunnable.java:226) ~[client-java-11.0.1.jar:na]
	at io.kubernetes.client.informer.cache.ReflectorRunnable.run(ReflectorRunnable.java:124) ~[client-java-11.0.1.jar:na]
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[na:na]
	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[na:na]
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[na:na]
	at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]

As we do not want to dissable log output for the whole SharedIndexInformer class, we wonder if the log level for this particular problem could be reduced to info?

** Client Version **
11.0.1

** Kubernetes Version **
1.19.6

** Java Version **
Java 11

To Reproduce
Have the SharedIndexInformer run a long time without changes in kubernetes.

Expected behavior
The log level should be INFO in this case as the watch gets fixed automatically.

Additional context
I reported this already in Issue #1580, but after updating to 11.0.1 the problem persists. I hope its ok to open a new issue as I was not able to reopen the old one.

[yue9944882]

@FlorianBuchegger re-establishing watch connection every ~5min is the expected behavior, but re-connecting too frequently will be another issue. how do you think about degrading this to WARN level?

[brendandburns]

@yue9944882 because this is expected and not an error (we handle it correctly as you say) perhaps this should actually be INFO or DEBUG?

[FlorianBuchegger]

@yue9944882 Exactly I think the behavior of the watch is perfectly fine and therefore it should not log an error on every reconnect. I would say the Loglevel in this case should be INFO or DEBUG as also @brendandburns suggested.

[FlorianBuchegger]

@yue9944882 any plans when a new version will be released?