Repository navigation
Intermittent hang at "Trying to resolve the latest version from remote" in setup-java@v4 #897
Description
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:
- Ubuntu
- macOS
- Windows
Runner type:
- Hosted
- Self-hosted (Current runner version: '2.325.0')
Repro steps:
- Configure a workflow using actions/setup-java@v4 with the following configuration:
- uses: actions/setup-java@v4 with: java-version: 17 distribution: temurin java-package: jdk check-latest: false server-id: github server-username: GITHUB_ACTOR server-password: GITHUB_TOKEN overwrite-settings: true
- Run the workflow multiple times
- Observe that sometimes the step completes normally, but other times it gets stuck at "Trying to resolve the latest version from remote" and never progresses
- The issue appears to be intermittent - same configuration works sometimes but fails other times
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
Activity
luna3m commentedon Aug 21, 2025
For me it's been failing intermittently the whole day.
jef commentedon Aug 21, 2025
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.
https://api.adoptium.net/v3/assets/version/%5B1.0,100.0%5D?project=jdk&vendor=adoptium&heap_size=normal&sort_method=DEFAULT&sort_order=DESC&os=linux&architecture=x64&image_type=jdk&release_type=ga&jvm_impl=hotspot&page_size=20&page=1
v-HarithaVattikuti commentedon Aug 21, 2025
Hi @leandroandrade-hotmart
Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.
endersonmenezes commentedon Aug 21, 2025
Same 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?
v-HarithaVattikuti commentedon Aug 21, 2025
Hello 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.
v-HarithaVattikuti commentedon Aug 21, 2025
Attaching another screenshot for reference.
josephlbarnett commentedon Aug 21, 2025
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.
nimjor commentedon Aug 22, 2025
We 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.v-HarithaVattikuti commentedon Aug 29, 2025
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:
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.
v-HarithaVattikuti commentedon Sep 9, 2025
Hi @leandroandrade-hotmart
Just a gentle reminder regarding this issue, If you have any updates or need further assistance, Please let us know.
v-HarithaVattikuti commentedon Oct 28, 2025
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
periyasamy003 commentedon Dec 29, 2025
@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: @main
Workflow snippet used:
Log Output:
v-priya-kinthali commentedon Jan 12, 2026
Hello @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!