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

Fechada
  • Algo errado?
#3,359 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Um pull request relacionado já foi integrado.

  • #3357 de @thymikee — integrado

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
15/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
ios, typescript
Domínio
backend, mobile

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
TypeScript
Estrelas
5.3k
Forks
377
Merge médio
14h 6min
PRs com merge (30d)
650

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de callstack/agent-device

Todas as issues de callstack/agent-device

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.