Intermittent hang at "Trying to resolve the latest version from remote" in setup-java@v4

[leandroandrade-hotmart]

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:

1. 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

2. Run the workflow multiple times
3. 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
4. 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

[luna3m]

For me it's been failing intermittently the whole day.

[jef]

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]

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]

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]

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]

Attaching another screenshot for reference.

[josephlbarnett]

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]

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 AggregateError for a timeout. Based on the "Gathering available versions from" line, one would assume the timeout was related to api.adoptium.net. However, we were able to successfully curl that 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 curl connected 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 temurin distribution as an example for debugging, but we saw the same behavior with corretto and zulu and adopt also. It is still unclear what broke and what the resolution was, but it was not happening to us with any of the other actions/setup-X actions.

[v-HarithaVattikuti]

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.

[v-HarithaVattikuti]

Hi @leandroandrade-hotmart
Just a gentle reminder regarding this issue, If you have any updates or need further assistance, Please let us know.