Repository navigation
Intermittent hang at "Trying to resolve the latest version from remote" in setup-java@v4 #897
Description
Activity
For me it's been failing intermittently the whole day.
Downgrading to v3 works. Something with the API. Not sure if it's doing any pagination. I only assume this because version 17 is on the next page of the API.
Reacted by Mike DolininHi @leandroandrade-hotmart
Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.Reacted by Leandro Andrade and nicolsssSame here, trying to update to v5.
(Self-hosted only on AWS | Not our on-premise runners)
(v2.328.0)
Edit: I looked at the code for v5 and v4 and found no difference in the Temurin Download file, I think the instability was in AWS.
@leandroandrade-hotmart your runners are in AWS too?
Reacted by Leandro AndradeHello everyone,
Temurin is included in the tool cache on GitHub-hosted runner images, as referenced here. Both v4 and v5 are functioning correctly, as shown in the screenshots. On ARM runners, where Temurin is not cached, it is downloaded as needed.
Please enable debug logging in your repository and share additional logs, as described in these instructions, to help further troubleshoot the issue.
Attaching another screenshot for reference.
here's what we saw on our self hosted runners -- immediate failure with no hint of what went wrong. by the time we tried enabling debug logs it was working again, but don't have high confidence that it will keep working.
Reacted by Nikolas AlveloWe were very confused by this on our self-hosted runners (AWS EKS). We had made zero changes to our network or infrastructure, but then these errors started happening. Even with the debug logging enabled, this action didn't provide enough useful output to troubleshoot. We ended up cloning the action into our private org so we could modify the action to debug it further. The screenshot below shows the error with debugging enabled:
Here we see the error type is
AggregateErrorfor a timeout. Based on the "Gathering available versions from" line, one would assume the timeout was related toapi.adoptium.net. However, we were able to successfullycurlthat host in a previous step in that same job:
Adding our own extra logging to the copied action revealed the IPs from the timeouts:
In
src/distributions/base-installer.ts:
You can see one of the timeouts is for the same IP that
curlconnected to successfully in the prior step in the same job:104.18.20.66.
It is unclear why this action had trouble connecting but curl did not. Again, this was in the same job, so the same ephemeral self-hosted runner. We just used the
temurindistribution as an example for debugging, but we saw the same behavior withcorrettoandzuluandadoptalso. It is still unclear what broke and what the resolution was, but it was not happening to us with any of the otheractions/setup-Xactions.Hello @nimjor , Thank you for your detailed investigation.
The intermittent hangs observed at "Trying to resolve the latest version from remote" are due to network-level issues when setup-java attempts to contact upstream JDK distribution APIs (such as Adoptium, Azul Zulu, and Corretto) over HTTPS. These APIs are served behind CDNs, so if an edge node becomes slow or unresponsive, the action can stall at that step.
Our findings show:
- The setup-java action uses Node.js HTTP requests, which by default have no timeout set. As a result, if a connection becomes slow or stalls mid-response, the request can hang indefinitely.
- In contrast, tools like curl may succeed in the same environment because:
- curl and Node.js may be routed to different CDN edge nodes, even when run from the same machine.
- curl includes retry logic by default, while Node.js does not unless explicitly configured.
- curl requests may time out and retry automatically, whereas Node.js will not unless timeouts are set.
We’re exploring improvements—specifically, enhancing logging so that failures surface the actual endpoint/IP involved, rather than just a generic “AggregateError.” This will aid in troubleshooting and improve reliability.
Thank you for your patience as we address this issue.
Reacted by Enderson Menezes (Mr. Enderson) and Mike DolininHi @leandroandrade-hotmart
Just a gentle reminder regarding this issue, If you have any updates or need further assistance, Please let us know.Hi All,
We’ve addressed this problem in PR #946, which enhances error logging for network failures to include endpoint/IP details and adds a retry mechanism for remote resolution. These improvements should prevent workflows from hanging indefinitely and provide clearer diagnostics in the event of network issues.Once the changes from PR #946 are merged and released, the setup-java action will handle such failures more robustly. If you continue to encounter related problems after updating to the latest version, please let us know.
Closing this issue as resolved by the improvements in PR #946. Thank you for your patience and detailed feedback
@HarithaVattikuti I am still experiencing the read ECONNRESET error even after testing with the latest changes on @main (which includes PR #946).
Environment:
Runner: Self-hosted Linux x64
Distribution: temurin
Version: @mainWorkflow snippet used:
- uses: actions/setup-java@main with: java-version: '21' distribution: 'temurin' check-latest: falseLog Output:
Trying to resolve the latest version from remote (node:435724) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Error: Java setup process failed due to: read ECONNRESETHello @periyasamy003👋,
Thank you for providing the details.
While the retry logic helps with temporary network issues, persistent ECONNRESET errors may still occur if there are ongoing network problems between the runner and the Java distribution servers.
If the issue still exists, could you please enable debug logging in your repository and share the additional logs as described here, or kindly open a new issue with all relevant logs and details to help us investigate further.
Thank you again!
Description:
I'm facing an intermittent issue where the actions/setup-java@v4 step gets stuck at "Trying to resolve the latest version from remote" and never completes. The pipeline hangs indefinitely at this step. This happens sporadically - sometimes the workflow runs successfully, other times it gets stuck at this exact point.
Task version:
actions/setup-java@v4
Platform:
Runner type:
Repro steps:
Expected behavior:
The setup-java action should consistently resolve the Java version and complete the setup process without hanging, regardless of when the workflow is executed. The step should either succeed or fail with a clear error message, not hang indefinitely.
Thanks