What happens
On a GitHub-hosted macOS runner, a job that connects with tailscale/github-action@v4 and then runs for several minutes gets cancelled ~5 min in with the generic The operation was canceled. Runner diagnostic logs (ACTIONS_RUNNER_DEBUG=true) show repeated job-lease renewal failures:
WARN GitHubActionsService] Attempt N of POST .../renewjob failed (Socket Error: HostNotFound)
ERR JobDispatcher] Catch exception during renew runner job ...
INFO JobDispatcher] Send job cancellation message to worker ...
The Actions broker hostname (run-actions-*.actions.githubusercontent.com) fails to resolve (HostNotFound), so the runner cannot renew its lease and the service cancels the healthy job.
Root cause
On join (macOS only), configureDNSOnMacOS in src/main.ts runs:
networksetup -setdnsservers Ethernet 100.100.100.100
repointing the runner's system DNS at the tailnet resolver, which intermittently fails to forward public queries — so the broker does not resolve, renewjob fails, and the job is cancelled. Three problems:
- Unconditional on macOS — gated only on the tailnet-wide
MagicDNSEnabled flag, not on --accept-dns. Passing args: --accept-dns=false does not prevent it (that only affects tailscale up, not the action's own networksetup call).
- No input to disable the DNS configuration.
- The action never restores DNS, so the override persists for the whole job.
Introduced by #200.
Impact
Any macOS job that stays up long enough to hit a lease renewal while the tailnet resolver cannot forward the broker query is silently cancelled. Intermittent, so it reads as flaky infrastructure.
Workaround
Revert DNS immediately after the action (safe when you do not need MagicDNS name resolution — reach peers by Tailscale IP):
- run: sudo networksetup -setdnsservers Ethernet Empty
Request
Make the macOS DNS configuration opt-in (or skip it when --accept-dns=false), and/or restore the original DNS in the post step. An input such as set-dns: false would suffice.
Environment
GitHub-hosted macOS (arm64), tailscale/github-action@v4, Tailscale 1.94.2.
What happens
On a GitHub-hosted macOS runner, a job that connects with
tailscale/github-action@v4and then runs for several minutes gets cancelled ~5 min in with the genericThe operation was canceled. Runner diagnostic logs (ACTIONS_RUNNER_DEBUG=true) show repeated job-lease renewal failures:The Actions broker hostname (
run-actions-*.actions.githubusercontent.com) fails to resolve (HostNotFound), so the runner cannot renew its lease and the service cancels the healthy job.Root cause
On join (macOS only),
configureDNSOnMacOSinsrc/main.tsruns:repointing the runner's system DNS at the tailnet resolver, which intermittently fails to forward public queries — so the broker does not resolve, renewjob fails, and the job is cancelled. Three problems:
MagicDNSEnabledflag, not on--accept-dns. Passingargs: --accept-dns=falsedoes not prevent it (that only affectstailscale up, not the action's ownnetworksetupcall).Introduced by #200.
Impact
Any macOS job that stays up long enough to hit a lease renewal while the tailnet resolver cannot forward the broker query is silently cancelled. Intermittent, so it reads as flaky infrastructure.
Workaround
Revert DNS immediately after the action (safe when you do not need MagicDNS name resolution — reach peers by Tailscale IP):
Request
Make the macOS DNS configuration opt-in (or skip it when
--accept-dns=false), and/or restore the original DNS in the post step. An input such asset-dns: falsewould suffice.Environment
GitHub-hosted macOS (arm64),
tailscale/github-action@v4, Tailscale 1.94.2.