Description:
JavaBase configures @actions/http-client with automatic retries and also wraps version resolution and download in a separate four-attempt retry loop. A single transient failure can therefore trigger multiplied requests and long, fixed delays. This increases load on vendor APIs and makes rate-limit recovery less predictable.
Use one bounded retry strategy for version resolution and downloads. It should use exponential backoff with jitter, honor Retry-After when available, retain the existing retryable HTTP statuses and network error codes, and log the attempt number and delay. Avoid accessing private console timer internals. Add deterministic unit tests with injected or mocked delay behavior.
Task version:
v6
Platform:
Runner type:
Repro steps:
Run the action against a distributor endpoint that repeatedly returns a retryable response such as HTTP 429 or 503, or simulate a retryable connection error.
Expected behavior:
The action performs a documented, bounded number of attempts using backoff and server-provided retry guidance, then succeeds or reports the final error.
Actual behavior:
Retries can occur at both the HTTP-client and installer layers, multiplying requests and using a fixed two-second delay that does not honor Retry-After.
Description:
JavaBaseconfigures@actions/http-clientwith automatic retries and also wraps version resolution and download in a separate four-attempt retry loop. A single transient failure can therefore trigger multiplied requests and long, fixed delays. This increases load on vendor APIs and makes rate-limit recovery less predictable.Use one bounded retry strategy for version resolution and downloads. It should use exponential backoff with jitter, honor
Retry-Afterwhen available, retain the existing retryable HTTP statuses and network error codes, and log the attempt number and delay. Avoid accessing private console timer internals. Add deterministic unit tests with injected or mocked delay behavior.Task version:
v6
Platform:
Runner type:
Repro steps:
Run the action against a distributor endpoint that repeatedly returns a retryable response such as HTTP 429 or 503, or simulate a retryable connection error.
Expected behavior:
The action performs a documented, bounded number of attempts using backoff and server-provided retry guidance, then succeeds or reports the final error.
Actual behavior:
Retries can occur at both the HTTP-client and installer layers, multiplying requests and using a fixed two-second delay that does not honor
Retry-After.