Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

ios: a shutdown under 1 s after close lets the open's runner prewarm boot the simulator again

Open
  • Is something wrong?
#3,359 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
ios, typescript
Domain
backend, mobile

Research direction

Start in packages/platform-apple/src/runner/runner-lifecycle.ts, following the stack from prewarmRunnerSession through ensureRunnerSession to startRunnerSessionWithLease, and compare with fenceRunnerStartAdmissionsForTeardown used on non-retained close. The owner decision (retaining close fencing the prewarm loop, or the loop refusing a device with no live session) comes first. Done means a unit test at that seam shows a prewarm attempt after a retaining close starts no runner, plus three live runs ending Shutdown.

Written by the indexing model from the issue text.

Description

needs-triage

Purpose

Track a path to the symptom in #3321 that #3357 does not cover: a simulator shut down with xcrun simctl shutdown right after close is booted again, this time by a runner the daemon starts, not by the retained runner. #3357 stops the retained runner; this is a different mechanism, so do not reopen #3357 for it.

Evidence

Measured on an iPhone 17 (iOS 27.0, Xcode 27.1 beta), Settings app, agent-device built from the #3357 branch, isolated --state-dir:

agent-device open com.apple.Preferences --relaunch --platform ios --udid "$A"
agent-device snapshot -i
sleep 2
agent-device close
xcrun simctl shutdown "$A"      # less than 1 s after close
  • 3 of 3 runs: the device shows Booted within 2 s, the original xcodebuild is gone, and about 15 s later the daemon (the parent of the new xcodebuild) has started a replacement runner. The device ends Booted with a runner alive and nothing reported.
  • Control: with 6 to 14 s between close and shutdown, 5 of 5 runs end Shutdown once #3357 is in. A longer gap is unaffected.
  • Origin of the replacement runner, from a stack trace on launchRunnerProcess: prewarmRunnerSession → prepareLocalIosRunner → runPrepareAttempt → ensureRunnerSession → startRunnerSessionWithLease. That is the open's background runner prewarm (packages/platform-apple/src/runner/runner-lifecycle.ts), whose attempt loop re-enters ensureRunnerSession when its runner is gone.
  • Not measured: a baseline on main without #3357, and whether the prewarm is still in its attempt loop when close runs or is re-entered by something else. Both decide the owner below.

Required behavior

  • A runner start that a prewarm loop makes after the session's close has retained the runner must not boot a device that was shut down in between.
  • Decide the owner. The #3357 watch cannot cover this: it only guards a retained runner, and here the runner that boots the device is a new session started by the prewarm loop. Candidates: a retaining close retires the prewarm loop's start admission for the device (non-retained close already fences admissions through fenceRunnerStartAdmissionsForTeardown), or the prewarm loop refuses to start a runner for a device with no live session.
  • Key the decision on session and admission state, never on a timing window or message text.

Completion

  • The sequence above, with shutdown under 1 s after close, ends with the device Shutdown and no daemon-spawned xcodebuild for it, in 3 of 3 live runs.
  • A test at the owning seam shows a prewarm attempt after a retaining close starts no runner.
  • Related: #3321, #3357.
Dominant language
TypeScript
Stars
4.9k
Forks
328
Avg merge
12h 16m
Merged PRs (30d)
538

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from callstack/agent-device

All issues in callstack/agent-device

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.