jiteshkhatri11 opened a new issue, #2151: URL: https://github.com/apache/maven-resolver/issues/2151
### New feature, improvement proposal ### Is your feature request related to a problem? Please describe. When resolving artifacts from remote repositories, Maven Resolver can fail immediately when a transient transport error occurs, such as a connection reset, read timeout, temporary DNS failure, or an HTTP 5xx response from an overloaded repository manager. This can be particularly problematic in CI/CD environments and large multi-module builds, where a single temporary network or repository-manager failure during an artifact download can cause the entire build to fail. For example, if one artifact download fails because of a temporary connection reset while many other transfers succeed, retrying that individual request shortly afterward might allow the build to continue successfully. Currently, there is no built-in resolver-level mechanism to retry such transient failures. Users can work around this by wrapping the entire Maven build in an external retry mechanism. However, this retries the whole build rather than only the failed transfer and may repeat compilation, testing, and other work that has already completed. A transport-level retry mechanism could handle transient failures closer to their source while allowing permanent failures, such as authentication errors or missing artifacts, to fail normally. ### Describe the solution you'd like Introduce an optional and configurable retry/backoff mechanism for transient transport failures. The mechanism could be configurable through `RepositorySystemSession` and integrated with the transport layer, while allowing individual transport implementations to control or opt out of retry behavior where appropriate. Possible configuration options could include: * Maximum retry attempts per transfer. * Fixed or exponential backoff. * Configurable base and maximum backoff delays. * Configurable HTTP status codes considered retryable. * Support for `Retry-After` when provided by the remote server. The implementation should follow these principles: * Retry only idempotent read operations such as `GET`/`GET_HEAD`. * Do not retry non-idempotent operations such as `PUT`. * Treat transient failures such as connection resets and read timeouts as potentially retryable. * Treat appropriate HTTP 5xx responses as retryable. * Allow `429 Too Many Requests` to be handled as retryable when appropriate. * Avoid retrying errors such as `401`, `403`, and `404`. * Do not treat checksum or integrity failures as ordinary retryable transport failures. * Respect `Retry-After` when supplied by the remote server. * Make retry attempts visible through the existing logging/transfer-listener infrastructure. * Keep the mechanism compatible with existing transport implementations and allow custom transporters to provide their own behavior or opt out. The default configuration should preserve the current behavior, with retries disabled unless explicitly configured. The exact configuration properties and API design could be determined during implementation to fit Maven Resolver's existing configuration and transport abstractions. ### Describe alternatives you've considered **External retry wrappers** Wrapping the entire Maven build in an external retry mechanism works today, but it retries the whole build instead of the individual failed transfer. This can repeat work that has already completed. **Repository manager failover or mirrors** Repository mirrors and failover mechanisms can help when an entire repository is unavailable, but they do not necessarily address transient failures affecting individual requests against an otherwise healthy repository. **Implementing retries in consumers** A consumer such as Maven could implement retry behavior independently. However, Maven Resolver is used by multiple consumers, and transport failures are encountered within the resolver. A common resolver-level mechanism could provide consistent behavior without requiring each consumer to implement its own solution. ### Additional context This proposal is related to the broader effort of improving the robustness of Maven Resolver's transport implementations. Related issues include: * #1640 — On server side errors (5xx) dump headers * #1744 — JDK HTTP Client Brotli support * #1974 — Connection pooling with `UrlTransporter` Configurable retries would complement this work by allowing transient transport failures to be handled without requiring users to retry an entire build. The proposal is designed to preserve existing behavior by default and limit retries to operations where retrying is safe. -- 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]
