GoogleContainerTools/jib · warning

${requestUrl} failed and will NOT be retried

Error message

${requestUrl} failed and will NOT be retried

What it means

FailoverHttpClient logs this warning when an HTTP request (method + URL) throws an IOException and the client has decided it cannot or will not retry it (retries exhausted or retry not supported). It is a diagnostic warning, not an exception itself; the underlying IOException still propagates.

Source

Thrown at jib-core/src/main/java/com/google/cloud/tools/jib/http/FailoverHttpClient.java:369

        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) {
    String log = "Failed to connect to " + url + " over HTTPS. Attempting again with HTTP.";
    logger.accept(LogEvent.warn(log));
  }

View on GitHub (pinned to fb949e2676)

Solutions

1. Inspect the URL in the message and test connectivity to the registry (curl the URL) to identify network/DNS/proxy issues
2. Check retry configuration and transient registry health; retry the build once the registry is reachable
3. Verify proxy settings (https.proxyHost/https.proxyPort or Jib sendCredentialsOverHttp-related flags) and VPN/firewall rules
4. If the failure is persistent, look at the wrapped IOException in the stack trace for the root cause

Example fix

// before: build fails with opaque network error
jib:build
// after: diagnose connectivity first
curl -v https://registry.example.com/v2/ && mvn jib:build

// check registry reachability before building
curl -fsS https://registry.example.com/v2/ || echo "registry unreachable: fix network/proxy before jib build"

try {
  jibBuild();
} catch (IOException e) {
  // logged as 'will NOT be retried'; decide on bounded manual retry
  if (isTransient(e) && attempts++ < 3) retryWithBackoff();
  else throw new BuildFailedException("registry unreachable: " + e.getMessage(), e);
}

When it happens

Trigger: A request to a registry (e.g. GET /v2/.../manifests/...) fails with an IOException after retries are exhausted, or the request does not support retry (e.g. non-idempotent operations or sendRetriesDisabled), so handleIOException returns false.

Common situations: Registry downtime or network flakiness exhausting retries; DNS failures; proxy misconfiguration; running behind a corporate firewall that blocks the registry; attempting writes (push) that are not retried after a transient failure.

Related errors

• ${requestUrl} failed and will 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/916d0fe7c0c2663d. Report an issue: GitHub.