GoogleContainerTools/jib · warning
${requestUrl} failed and will be retried
Error message
${requestUrl} failed and will be retried What it means
Jib's FailoverHttpClient installs an HttpBackOffIOExceptionHandler that retries requests after transient IOExceptions with exponential backoff. When a retry will happen it logs "<METHOD> <url> failed and will be retried"; when retries are exhausted it logs the 'will NOT be retried' variant.
Source
Thrown at jib-core/src/main/java/com/google/cloud/tools/jib/http/FailoverHttpClient.java:366
try {
Response response = new Response(httpRequest.execute());
synchronized (responsesCreated) {
responsesCreated.add(response);
}
return response;
} catch (HttpResponseException ex) {
throw new ResponseException(ex, clearAuthorization);
}
}
private HttpIOExceptionHandler createBackOffRetryHandler() {
return new HttpBackOffIOExceptionHandler(new ExponentialBackOff()) {
@Override
public boolean handleIOException(HttpRequest request, boolean supportsRetry)
throws IOException {
String requestUrl = request.getRequestMethod() + " " + request.getUrl();
if (super.handleIOException(request, supportsRetry)) {
logger.accept(LogEvent.warn(requestUrl + " failed and will be retried"));
return true;
}
logger.accept(LogEvent.warn(requestUrl + " failed and will NOT be retried"));
return false;
}
};
}
private HttpTransport getHttpTransport(boolean secureTransport) {
HttpTransport transport =
secureTransport ? secureHttpTransportFactory.get() : insecureHttpTransportFactory.get();
synchronized (transportsCreated) {
transportsCreated.add(transport);
}
return transport;
}
private void logHttpFailover(URL url) {View on GitHub (pinned to fb949e2676)
Solutions
- Usually no action needed — Jib retries automatically with exponential backoff
- If warnings recur until 'will NOT be retried', check network/proxy connectivity to the registry
- Configure credentials/CA certs if TLS interception is causing connection failures
- Retry the build after the network stabilizes
Example fix
// before (shell) mvn jib:build # fails behind corporate proxy // after export HTTPS_PROXY=http://proxy.corp:8080 export JIB_CLIENT_TIMEOUT=60000 mvn jib:build
Defensive patterns
Strategy: retry
Validate before calling
// Pre-check registry connectivity before building curl -fsS --max-time 10 https://registry-1.docker.io/v2/ >/dev/null && echo "registry reachable" || echo "network issue: expect retries"
Try / catch
boolean ok = new HttpBackOffIOExceptionHandler(new ExponentialBackOff())
.handleIOException(request, supportsRetry);
if (!ok) {
logger.warn("{} failed and will NOT be retried; check network/proxy", requestUrl);
} Prevention
- Treat single 'will be retried' warnings as transient; only act if they repeat
- Ensure proxies/VPN/registry endpoints are reachable from CI runners
- Increase client timeout or backoff settings on flaky networks
- Verify DNS and TLS interception configuration for registry hosts
When it happens
Trigger: handleIOException fires on any IOException from an HTTP request made through FailoverHttpClient (connection reset, timeout, DNS hiccup) while super.handleIOException still permits retries; the warning is emitted for each retried attempt.
Common situations: Flaky corporate proxies or VPNs; registry rate limiting dropping connections; temporary DNS failures; network interruptions in CI runners.
Understand the failure class
Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.
Related errors
- ${requestUrl} failed and will NOT be retried
- Path does not start with forward slash (/): ${unixPath}
- Cannot create AbsoluteUnixPath from non-absolute Path: ${pat
- Cannot resolve against absolute Path: ${relativePath}
- platforms set cannot be empty
AI-assisted analysis of GoogleContainerTools/jib@fb949e2676 (2026-09-06).
Data as JSON: /api/errors/676cebaca102e3e0.
Report an issue: GitHub.