ahus1 commented on issue #2151: URL: https://github.com/apache/maven-resolver/issues/2151#issuecomment-6311329931
This matches what we see in CI. Some data points: in the last few days we saw several builds fail on a single artifact download from Maven Central, while thousands of other downloads in the same job succeeded, and most passed when simply re-run. Most were `502 Bad Gateway` responses. One was `Connection reset`. I looked at how this behaves today, with Maven 3.9.16 (Resolver 1.9.27, native HTTP transport): - `aether.connector.http.retryHandler.count` (default 3) retries I/O errors, but I saw a `Connection reset` that still failed after about three attempts one second apart. - `aether.connector.http.retryHandler.serviceUnavailable` (default `429,503`, since 1.9.16) already provides back-off with `Retry-After` support. A `502` is not in that default list, so it is not retried at all, and the build fails on the first one. - Setting `-Daether.connector.http.retryHandler.serviceUnavailable=429,502,503,504` works around it, but you have to know to do that. So part of this issue seems already addressed by the existing mechanism, and the remaining gap for HTTP is the default status code list. Would it make sense to treat `502` and `504` like `429` and `503` by default, as they are also typical transient gateway or CDN errors? If you prefer to keep the defaults conservative, documenting `502` and `504` as recommended values for CI use would also help. Either way, back-off with a bounded total wait keeps the downside small, and non-transient statuses (`401`, `403`, `404`) would stay non-retryable. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
