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

  1. Usually no action needed — Jib retries automatically with exponential backoff
  2. If warnings recur until 'will NOT be retried', check network/proxy connectivity to the registry
  3. Configure credentials/CA certs if TLS interception is causing connection failures
  4. 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

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


AI-assisted analysis of GoogleContainerTools/jib@fb949e2676 (2026-09-06). Data as JSON: /api/errors/676cebaca102e3e0. Report an issue: GitHub.