[SDK Sentinel] Retry automatic dev server port collisions

[sdk-sentinel-bot]

Caution

This PR contains untrusted AI-generated code. Do not approve or run CI until a maintainer has reviewed the diff. SDK Sentinel verified that GitHub Actions remained approval-gated with zero executable jobs when this PR was opened.

Summary

• CI evidence: failed CI job · workflow run · last known pass · first known failure

Stabilize automatic Temporal dev-server startup. The CLI-backed suite passed in the [preceding CI run](https://github.com/temporalio/sdk-java/actions/runs/33017156613) and failed in the [first captured bad run](https://github.com/temporalio/sdk-java/actions/runs/33024141969) when its selected loopback port was already occupied. There are no breaking changes and no server PR is required.

Root cause

Automatic selection opened an ephemeral-port probe and closed it before spawning the CLI. Another process could claim that port during the resulting time-of-check/time-of-use gap, causing the CLI listener to exit.

Fix

When the launcher selected the port, retry with a fresh port only after a recognized address-in-use failure. Explicit ports and unrelated startup failures remain single-attempt. Add an integration test that deliberately occupies the first selection.

Validation

Changed source and test classes compile, module formatting passes, and four loopback forced-collision checks recovered successfully. The unchanged baseline passed. Full validation and JUnit execution remain required in CI because this sandbox cannot update submodule metadata and lacks the offline JUnit runtime.

Validation status: validation-incomplete

• Flake confidence: high
• Fix confidence: medium
• Value: medium
• Patch scope: standard — 2 changed files; 5.8 KiB
• Local reproduction: reproduced — A loopback check forced the first automatic port to be occupied, reproducing the bind collision; the candidate recovered on all four attempts. Natural scheduling reproduction was not attempted.
• Regression coverage: not-run — A deterministic pinned-CLI integration test was added and compiled, but its JUnit runtime was unavailable in the offline cache. Equivalent standalone checks passed.
• Unchanged baseline (Gradle formatting and test-source compilation) — passed
• Independent candidate (Gradle formatting and test-source compilation) — did not pass (failure)

Investigator-run checks

• .ci-flake-runtime/input/validate.sh (trusted unchanged baseline) — passed; 1 attempt(s). The unchanged baseline completed spotlessCheck and testClasses successfully.
• Focused Gradle JUnit execution attempts for TemporalDevServerLauncherIntegrationTest — failed; 3 attempt(s). JUnit execution was blocked by read-only submodule metadata and then unavailable offline runtime artifacts.
• Loopback ForcedPortCollisionCheck using the pinned Temporal CLI — passed; 4 attempt(s). Each attempt deliberately occupied the first selected port; the launcher selected a second port, started successfully, and shut down.
• ./gradlew --offline --no-daemon :temporal-testing:testClasses -x :temporal-serviceclient:initSubmodules -x :temporal-serviceclient:updateSubmodules -x :temporal-sdk:compileJava17Java — passed; 1 attempt(s). Affected Java 8-compatible production and test classes compiled successfully.
• ./gradlew --offline --no-daemon :temporal-testing:spotlessCheck — passed; 1 attempt(s). Formatting checks for the changed module passed.
• .ci-flake-runtime/input/validate.sh — failed; 1 attempt(s). Candidate validation stopped when Gradle attempted to write read-only .git submodule configuration; this was an investigation-sandbox limitation.

Required target CI

• Continuous Integration / Unit test with CLI on Linux and Java 11, including TemporalDevServerLauncherIntegrationTest
• .ci-flake-runtime/input/validate.sh in a checkout with writable submodule metadata

Residual risks

• Recovery depends on recognizable CLI address-in-use text.
• Three consecutive collisions can still exhaust the bounded retry.
• The added JUnit test and full canonical validation did not execute locally.

Automation provenance

• Investigator workflow
• Base SHA: 6d5ba591bb405da453870c85767599777ade0241

If this finding should not be fixed, apply the sdk-sentinel:false-positive label and close the PR. Sentinel will suppress the finding until its affected source changes.

SDK Sentinel recurrence history

• Unique failed CI run attempts: 1
• First occurrence: 2026-08-26 23:54 UTC
• Latest occurrence: 2026-08-26 23:54 UTC
• Recent occurrences:
  • 2026-08-26 23:54 UTC — failed CI job