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

[Csmolina]

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

[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?

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

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