Error: ENOENT: no such file or directory, copyfile '/home/runner/work/_temp/...' -> '/opt/hostedtoolcache/ghcup/0.1.50.2/x64/ghcup'

[ocramz]

Background:

I had a successfully cached build, and at the next push this failure showed up.

Error log

Run haskell-actions/setup@v2
Preparing to setup a Haskell environment
Resolved ghc 9.10 to 9.10.3
Resolved cabal latest to 3.16.1.0
Resolved stack latest to 3.7.1
Preparing ghcup environment
Preparing ghc environment
  node:internal/fs/promises:624
    return await PromisePrototypeThen(
           ^
  
  Error: ENOENT: no such file or directory, copyfile '/home/runner/work/_temp/9bff0ef5-6540-4b8b-8632-b04c9628f5d0' -> '/opt/hostedtoolcache/ghcup/0.1.50.2/x64/ghcup'
      at async Object.copyFile (node:internal/fs/promises:624:10) {
    errno: -2,
    code: 'ENOENT',
    syscall: 'copyfile',
    path: '/home/runner/work/_temp/9bff0ef5-6540-4b8b-8632-b04c9628f5d0',
    dest: '/opt/hostedtoolcache/ghcup/0.1.50.2/x64/ghcup'
  }
  
  Node.js v24.11.1

[nikita-volkov]

Just came here to report the same issue. This issue is flaky, rerunning eventually makes the build pass.

Here's an example. See the failed jobs. Rerunning the same build eventually succeeded.

[DigitalBrains1]

Another error I see, alternating with the mentioned ENOENT, is:

  /opt/hostedtoolcache/ghcup/0.1.50.2/x64/ghcup config add-release-channel vanilla
  node:internal/child_process:421
      throw new ErrnoException(err, 'spawn');
            ^
  
  Error: spawn ETXTBSY
      at ChildProcess.spawn (node:internal/child_process:421:11)
      at Object.spawn (node:child_process:796:9)
      at ToolRunner.<anonymous> (/home/runner/work/_actions/haskell-actions/setup/v2/dist/index.js:1644:34)
      at Generator.next (<anonymous>)
      at /home/runner/work/_actions/haskell-actions/setup/v2/dist/index.js:1258:71
      at new Promise (<anonymous>)
      at __webpack_modules__.6665.__awaiter (/home/runner/work/_actions/haskell-actions/setup/v2/dist/index.js:1254:12)
      at /home/runner/work/_actions/haskell-actions/setup/v2/dist/index.js:1626:53
      at new Promise (<anonymous>)
      at ToolRunner.<anonymous> (/home/runner/work/_actions/haskell-actions/setup/v2/dist/index.js:1626:20) {
    errno: -26,
    code: 'ETXTBSY',
    syscall: 'spawn'

as here.

It sounds like multiple processes are racing for these files? ENOENT suggests maybe the other process has already copied and subsequently deleted the file, while ETXTBUSY suggests one process is executing the binary in question while another process is writing the binary itself.

[andreasabel]

It is likely that I introduced this bug here: eb29c23

setup/src/setup-haskell.ts

Lines 43 to 50 in 5757174

	await core.group(`Preparing ghcup environment`, async () => {
	// Andreas Abel, 2026-01-01, https://github.com/haskell-actions/setup/issues/78
	// Add ghcup vanilla and prereleases channels by default.
	addGhcupReleaseChannel('vanilla', os, arch);
	addGhcupReleaseChannel('prereleases', os, arch);
	if (opts.ghcup.releaseChannel)
	addGhcupReleaseChannel(opts.ghcup.releaseChannel.toString(), os, arch);
	});

It could be that the three invokations of addGhcupReleaseChannel are running a race here.
(I had assumed that with all the Promises and await this code base was concurrency proof.)

I am not really fluent in TypeScript, maybe someone can show me how to do this correctly?
A workaround could be to make a single call, adding several release channels at the same time.

[andreasabel]

Ok, sprinkling in more awaits seems to fix the problem:

• await addGhcupReleaseChannel #135

[andreasabel]

Thanks @ocramz @nikita-volkov @DigitalBrains1 for the report!
I fixed 2.10.1 so please try again.

[DigitalBrains1]

I ran 25 CI jobs with 7786314 and they all no longer exhibit this issue! Thanks for the rapid fix!

[ocramz]

@andreasabel thank you for the quick update! do you recommend we pin our CI stages to a specific commit hash to prevent this sort of thing from happening?

[andreasabel]

@ocramz Well, if you are asking for precise ghc-versions (like 9.10.2 rather than 9.10) then you seldomly need to update the action version, because most updates just add the latest GHC versions to the list of known versions---and those are used to resolve e.g. 9.10 to 9.10.3 and latest to whatever latest. In this case, it can make sense to pin the action version.
Otherwise, no, I guess you just spend more time bumping the action version to always get the latest GHC minors.