Description:
setup-java starts dependency cache restoration before JDK installation so the two operations overlap, but it does not observe a rejected restore promise until after Java installation and Maven configuration finish. If cache restoration rejects first, Node can treat it as an unhandled rejection and terminate the action before the intended core.setFailed path. This can also mask a simultaneous Java setup failure.
The cache input is currently validated only inside cache restoration, after distribution setup has already started. Invalid providers such as cache: unsupported should fail before expensive JDK side effects.
Task version:
v6 and current main
Platform:
Runner type:
Repro steps:
- Run
setup-java with dependency caching enabled and make JDK setup remain pending (for example, defer the distribution's setupJava promise).
- Cause cache restoration to reject immediately, either with an invalid
cache value or a missing dependency file.
- Observe that the cache promise rejects before
setup-java.ts reaches its later await cacheRestore.
A deterministic unit reproduction defers setupJava while mocking cache restoration to reject immediately.
Expected behavior:
Cache restoration should continue to overlap JDK installation, while every rejection is observed immediately. If Java setup/configuration and cache both fail, the setup error should take precedence. If setup succeeds and cache fails, the cache error should be reported through core.setFailed. Invalid cache input should fail before distribution installation.
Actual behavior:
An early cache rejection is temporarily unhandled and can terminate the action outside the intended error handling. Invalid cache input is discovered only after distribution setup has started.
Proposed direction:
Validate cache provider input through a shared validation path before starting Java setup. Convert the cache restore promise immediately into a settled/discriminated result, keep it running in parallel with Java installation, and reconcile the result afterward with deterministic setup-error precedence.
Description:
setup-javastarts dependency cache restoration before JDK installation so the two operations overlap, but it does not observe a rejected restore promise until after Java installation and Maven configuration finish. If cache restoration rejects first, Node can treat it as an unhandled rejection and terminate the action before the intendedcore.setFailedpath. This can also mask a simultaneous Java setup failure.The
cacheinput is currently validated only inside cache restoration, after distribution setup has already started. Invalid providers such ascache: unsupportedshould fail before expensive JDK side effects.Task version:
v6 and current
mainPlatform:
Runner type:
Repro steps:
setup-javawith dependency caching enabled and make JDK setup remain pending (for example, defer the distribution'ssetupJavapromise).cachevalue or a missing dependency file.setup-java.tsreaches its laterawait cacheRestore.A deterministic unit reproduction defers
setupJavawhile mocking cache restoration to reject immediately.Expected behavior:
Cache restoration should continue to overlap JDK installation, while every rejection is observed immediately. If Java setup/configuration and cache both fail, the setup error should take precedence. If setup succeeds and cache fails, the cache error should be reported through
core.setFailed. Invalid cache input should fail before distribution installation.Actual behavior:
An early cache rejection is temporarily unhandled and can terminate the action outside the intended error handling. Invalid cache input is discovered only after distribution setup has started.
Proposed direction:
Validate cache provider input through a shared validation path before starting Java setup. Convert the cache restore promise immediately into a settled/discriminated result, keep it running in parallel with Java installation, and reconcile the result afterward with deterministic setup-error precedence.