StandardHttpClient.retryWithExponentialBackoff leads to TimeoutException hiding underlying issues

[manusa]

Description

The changes to provide a generic retry approach (#4825 #4788) in combination with OperationSupport.waitForResult and the default retry values:

kubernetes-client/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/dsl/internal/OperationSupport.java

Lines 502 to 532 in ee38b09

	protected <T> T waitForResult(CompletableFuture<T> future) throws IOException {
	try {
	// since readTimeout may not be enforced in a timely manner at the httpclient, we'll
	// enforce a higher level timeout with a small amount of padding to account for possible queuing
	if (getRequestConfig().getRequestTimeout() > 0) {
	return future.get(getRequestConfig().getRequestTimeout() + ADDITIONAL_REQEUST_TIMEOUT, TimeUnit.MILLISECONDS);
	}
	return future.get();
	} catch (InterruptedException e) {
	Thread.currentThread().interrupt();
	InterruptedIOException ie = new InterruptedIOException();
	ie.initCause(e);
	throw ie;
	} catch (ExecutionException e) {
	Throwable t = e;
	if (e.getCause() != null) {
	t = e.getCause();
	}
	// throw a new exception to preserve the calling stack trace
	if (t instanceof IOException) {
	throw new IOException(t.getMessage(), t);
	}
	if (t instanceof KubernetesClientException) {
	throw ((KubernetesClientException) t).copyAsCause();
	}
	throw new KubernetesClientException(t.getMessage(), t);
	} catch (TimeoutException e) {
	future.cancel(true);
	throw KubernetesClientException.launderThrowable(e);
	}
	}

lead to TimeoutException that hides the underlying issue that's causing the overhead with the retry and backoff intervals.

We should try to find a way to report the last/latest status code/message (if any) and report it when the timeout happens.