Recover ConfigMap refresh tasks after transient API failures #4976

Problem

KubernetesFromConfigMapProcessor calls fullyRefreshCache directly from a scheduleAtFixedRate task. The default polling getter wraps API failures in IllegalStateException. An uncaught exception from a periodic scheduled task suppresses all subsequent executions of that task, permanently freezing the injected configuration until restart.

Locations:

• spring/src/main/java/io/kubernetes/client/spring/extended/manifests/KubernetesFromConfigMapProcessor.java:82-88,95-110
• spring/src/main/java/io/kubernetes/client/spring/extended/manifests/configmaps/PollingConfigMapGetter.java:38-42

Reproduction

1. Initialize an annotated bean with a successful ConfigMap read.
2. Make a later scheduled read fail once (for example, an HTTP 500 or a connection failure).
3. Restore the API server and change the ConfigMap.
4. Observe that subsequent refreshes never execute and the injected map stays stale.

Impact

One transient failure can permanently disable dynamic configuration updates. Suggested priority: medium.

Requested fix and acceptance criteria

• Keep scheduled refreshes running after recoverable read failures.
• Preserve the last successfully observed data during transient failures.
• Report failures using repository-standard logging; do not silently swallow exceptions or convert errors into successful empty configurations.
• Preserve intentional initialization/fail-fast semantics unless a change is required and documented.
• Add a regression test covering successful initialization, a failed scheduled refresh, and later recovery to new data.
• Separate issues address cache isolation, cadence, and atomic publication. Avoid bundling those independent fixes here.

Agent instructions

Implement the fix, run relevant regression tests, and open a pull request referencing and closing this issue. Follow the repository's PR template and contribution conventions. Other agents may change this processor; keep the patch tightly scoped.