stablyai/orca · error · Error

Timed out after ${options.timeoutMinutes}m waiting for mac r

Error message

Timed out after ${options.timeoutMinutes}m waiting for mac release build workflow ${workflowRunId}.

What it means

Thrown by waitForReleaseMacBuildRun when the deadline (now + options.timeoutMinutes*60*1000, default 90m via RELEASE_MAC_BUILD_TIMEOUT_MINUTES) passes while the run's status is still not 'completed'. The run exists and is reachable but never finished in the allotted window.

Source

Thrown at config/scripts/run-release-mac-build-workflow.mjs:136

  const deadlineMs = now() + options.timeoutMinutes * 60 * 1000

  while (now() <= deadlineMs) {
    const run = await api.request(
      'GET',
      `/repos/${api.owner}/${api.repo}/actions/runs/${workflowRunId}`
    )

    if (run.status === 'completed') {
      return run
    }

    console.log(
      `Mac release build workflow is ${run.status}; polling again in ${options.pollSeconds}s`
    )
    await sleep(options.pollSeconds * 1000)
  }

  throw new Error(
    `Timed out after ${options.timeoutMinutes}m waiting for mac release build workflow ${workflowRunId}.`
  )
}

export function createGitHubApiClient(options, deps = {}) {
  const fetchImpl = deps.fetch ?? globalThis.fetch
  if (typeof fetchImpl !== 'function') {
    throw new Error('A fetch implementation is required.')
  }

  const [owner, repo] = options.repo.split('/')
  if (!owner || !repo) {
    throw new Error(`GITHUB_REPOSITORY must be in owner/repo form, got "${options.repo}".`)
  }

  return {
    owner,
    repo,

View on GitHub (pinned to 1136503c6a)

Solutions

Raise RELEASE_MAC_BUILD_TIMEOUT_MINUTES to cover realistic mac build + queue time.
Open the run URL and check whether it is queued (runner capacity) vs in_progress (stalled step).
For capacity issues, add mac runners or use larger instances; for stalls, fix the hanging step.
Re-dispatch once capacity is available.

Example fix

# before
env: RELEASE_MAC_BUILD_TIMEOUT_MINUTES=45
# after
env: RELEASE_MAC_BUILD_TIMEOUT_MINUTES=120

Defensive patterns

Strategy: retry

Validate before calling

const timeoutMinutes = readPositiveInteger(env.RELEASE_MAC_BUILD_TIMEOUT_MINUTES, 90)
if (timeoutMinutes < 120) {
  console.warn('mac builds can exceed 90m; consider RELEASE_MAC_BUILD_TIMEOUT_MINUTES=120')
}

Type guard

function isCompleted(run) { return run?.status === 'completed' }

Try / catch

try {
  await waitForReleaseMacBuildRun(api, workflowRun.id, options)
} catch (err) {
  if (/Timed out .* waiting for mac release build/.test(err.message)) {
    // re-poll with an extended timeout only after confirming the run is still in_progress
  }
  throw err
}

Prevention

Set RELEASE_MAC_BUILD_TIMEOUT_MINUTES to cover queue + build + notarization worst case.
Watch for queued-vs-in_progress to distinguish capacity from stalls.
Alert on repeated timeouts rather than silently lengthening the window.

When it happens

Trigger: Polling GET .../actions/runs/<id> keeps returning status in (queued, in_progress, waiting, ...) until the timeout elapses; conclusion is never reached.

Common situations: macOS runners are scarce/slow (long queue), the build genuinely hangs (notarization stall), timeoutMinutes too low for cold first builds, runner lost and GitHub slow to mark failure.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

AI-assisted analysis of stablyai/orca@1136503c6a (2026-08-12). Data as JSON: /api/errors/61b03924eea3f9e7. Report an issue: GitHub.