[macOS runner] Identical twin repos throw different results when running the same workflow

[martincapello]

Describe the bug
We started getting the following output when running a workflow in a private repository a few days ago:

The issue is the part where it says:

/var/folders/y6/nj790rtn62lfktb1sh__79hc0000gn/T/createdmg.tmp.XXXXXXXXXX.JeR9Zh8CMa:396:408: execution error: Finder got an error: AppleEvent timed out. (-1712)

After a long search of similar issues and trying lots of possible fixes without luck. I ended up creating a new private repository with the same content as the one I was using, in other words, I made a copy.
Then to my surprise, running the same workflow in this repository outputs the following:

Which is good, because the following error is the one I was expecting:

/var/folders/y6/nj790rtn62lfktb1sh__79hc0000gn/T/createdmg.tmp.XXXXXXXXXX.iVOkU1Q0Yj:1019:1074: execution error: Finder got an error: Can’t set item "Aseprite.app" of disk "dmg.DKz77u" to true. (-10006)

To Reproduce
There is no way to reproduce this...in fact there were a few times that the workflow succeeded at the original repository...so it seems like a random behavior with a probability of failure of 99%. In the other hand, in the copied repository the workflow run always works.
EDIT: I've found out that is actually fails every single time when the Set up job outputs this data:

Runner Image Provisioner
  Hosted Compute Agent
  Version: 20250620.352
  Commit: f262f3aba23b10ea191b2a62bdee1ca4c3d344da
  Build Date: 2025-06-20T19:27:17Z
Runner Image
  Image: macos-14-arm64
  Version: 20250623.1617

Expected behavior
As shown in the above screenshot for the repository copy.

Runner Version and Platform

This is the data of the runner that executes the workflow that fails:

This is the data of the runner that executes the workflow that succeed:

So, I'm wondering if for some reason the runner for the original repository is broken in some way...then by making a copy, the new repository got a new fresh runner that is not broken...I don't really know.

Is there any way to reassign a runner to a repository? Or something like that? Because otherwise we will have to use the repository copy, and destroy the original, but we will have to recreate all the secrets in the new repo...which is really annoying to say the least.

[mwestphal]

Hi @martincapello

I have the exact same issue in a public repo:
https://github.com/f3d-app/f3d-superbuild/actions/runs/15915150231/attempts/1

The packaging step fails with:

2025-06-27T06:11:45.5507740Z CPack: Create package
2025-06-27T06:11:45.5509010Z CPack Verbose: Package files to: /Users/runner/work/f3d-superbuild/f3d-superbuild/build/_CPack_Packages/Darwin/DragNDrop/F3D-3.1.0-120-ga647d97c-macOS-x86_64-raytracing.dmg
2025-06-27T06:11:45.5511440Z CPack Error: Error executing: osascript "/Users/runner/work/f3d-superbuild/f3d-superbuild/build/cpack/f3d/DragNDrop/build/f3d-dmg-setup.scpt" "F3D-3.1.0-120-ga647d97c-macOS-x86_64-raytracing"
2025-06-27T06:11:45.5513070Z CPack Error: Error executing custom script on disk image.
2025-06-27T06:11:45.5514690Z /Users/runner/work/f3d-superbuild/f3d-superbuild/build/cpack/f3d/DragNDrop/build/f3d-dmg-setup.scpt:557:606: execution error: Finder got an error: AppleEvent timed out. (-1712)
2025-06-27T06:11:45.5516020Z 
2025-06-27T06:11:45.5516220Z CPack Error: Problem compressing the directory
2025-06-27T06:11:45.5516780Z CPack Error: Error when generating package: F3D
2025-06-27T06:11:45.5517920Z CMake Error at /Users/runner/work/f3d-superbuild/f3d-superbuild/source/superbuild/cmake/scripts/package_test.cmake:25 (message):
2025-06-27T06:11:45.5519130Z   CPack failed with exit code 1

The only different between this run and the previous run that did not fail is the "Runner Image Provisioner":

Failure:

Runner Image Provisioner
  Hosted Compute Agent
  Version: 20250620.352
  Commit: f262f3aba23b10ea191b2a62bdee1ca4c3d344da
  Build Date: 2025-06-20T19:27:17Z

Success:

Runner Image Provisioner
  2.0.437.1+b8a73daf41ec39b19236c1d542c9f2348c5b7c2d

I have no idea why the formatting of the provisionner changed and what it means really.

[martincapello]

Feels good not to be alone 🙂

[martincapello]

Also, it seems that that Runner Image Provisioner is broken...I have taken some screenshots using screencapture command and these are the results:

When the (broken) Runner Image Provisioner is selected to do the job I got this screenshot:

When the other Runner Image Provisioner is selected to do the job I got this one:

So, there is some issue there...

[mwestphal]

So we manage to fix it. There was a bug in our packaging script that somehow did not cause any issue before the runner provisioner change. No idea why.

You can find the fix here if that helps: f3d-app/f3d-superbuild#243

(It was an indentation error, the fix is hard to read)

[martincapello]

Oh man...deterministic computation is becoming something rare these days...will try with some indentation changes to see if it works for us as well...but this is crazy...thank you for letting me know! Will see what happens...

[martincapello]

Okay, it didn't work for us. Not even using a script as simple as this:

on run (volumeName)
  tell application "Finder"
    tell disk (volumeName as string)
      log "open"
      open
      log "close"
      close
    end tell
  end tell
end run

It just logs open and throws the same execution error: Finder got an error: AppleEvent timed out. (-1712) error every single time.

One thing to note here is that in our case we are using the macos-latest image (macos-14-arm at the moment) and in yours it is macos-13 (as I was able to see in your builds). If I use the macos-13 runner, the script works as expected. We will see if we can use macOS 13 as a workaround...but this is insane, since using another provisioner makes the macos-14 image work...

UPDATE: I'm sorry @mwestphal I forgot to thank you for sharing your fix!

[mwestphal]

No worries, I hope you manage to make it work at some point.

[martincapello]

I have created a github ticket referencing this issue a couple of days ago and got a reply. This is the main public tracking issue:
actions/runner-images#12482

Which is exactly the same as we are experiencing.

[martincapello]

I'm closing this because seems that actions/runner-images#12510 fixed this issue.