Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

ios: a shutdown within seconds of close lets the open's runner prewarm boot the simulator again

Chiusa
  • Qualcosa non va?
#3,359 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #3357 di @thymikee — integrata

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
15/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
ios, typescript
Ambito
backend, mobile

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
TypeScript
Stelle
4.9k
Fork
328
Merge medio
12h 18m
PR unite (30g)
538

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di callstack/agent-device

Tutte le issue di callstack/agent-device

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.