You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried to do a waitUntilCondition call, that eventually errorred out with a resource too old exception. This seems to come from WatcherException isShouldRetry - it explicitly is false when there's an http gone exception.
It should either be the other way around, or to retry no matter what the exception is.
After this change the internal wait code can be mostly cleaned up: 63d555d (not all of the tests were updated yet)
However that code shows there is inconsistent handling of the interrupted exception. At least for our own internal usage it would be better to not throw it directly from waitUntilCondition and instead use a KubernetesClientException. Since the proposed change is already breaking wrt exception handling, could we make that change as well?
The only remaining waiting scenario is a pod list scenario, which could be addressed by #3278
...interrupted exception....instead use a KubernetesClientException...
I guess that now that the underlying behavior has changed, it no longer makes sense to have it as part of the method signature.
The change should not be breaking (strictly speaking) since KubernetesClientException is unchecked
Activity
fix fabric8io#3271: refining the wait logic
shawkins commentedon Jun 28, 2021
After this change the internal wait code can be mostly cleaned up: 63d555d (not all of the tests were updated yet)
However that code shows there is inconsistent handling of the interrupted exception. At least for our own internal usage it would be better to not throw it directly from waitUntilCondition and instead use a KubernetesClientException. Since the proposed change is already breaking wrt exception handling, could we make that change as well?
The only remaining waiting scenario is a pod list scenario, which could be addressed by #3278
fix fabric8io#3271: refining the wait logic
manusa commentedon Jun 29, 2021
The change should not be breaking (strictly speaking) since KubernetesClientException is unchecked
fix fabric8io#3271: refining the wait logic