Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

iOS: a canceled request releases the session lock while its runner command still runs on the device

クローズ
  • 何か問題がありますか？
#3,383 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

関連するプルリクエストがすでにマージされています。

  • #3385 @thymikee による — マージ済み

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
22/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
ios, typescript
領域
backend, mobile

調査の方向性

Start in src/daemon/request-execution-locks.ts and packages/kernel/src/keyed-lock.ts to see when the session and device locks are released, then in packages/platform-apple/src/runner/runner-exchange.ts where an abandoned charge is marked. Done means a test in which a canceled runner command keeps the session lock until the runner journal reports it terminal, plus the live iOS press-then-relaunch check. Linked PR #3385 is already open against this, so check it before starting.

索引モデルが issue の本文から書いたものです。

説明

Problem

A per-call signal (#3178) cancels a request, but on iOS the daemon releases the session's lock before the device has finished the canceled work. The next request on the same session can then run while the aborted command is still executing on the device.

  • The per-session and per-device keyed locks are held by the handler's promise (request-execution-locks.ts, keyed-lock.ts).
  • On abort, the runner fetch rejects at once, the exchange marks the charge abandoned and rethrows (runner-exchange.ts), and the handler settles. The lock is released.
  • The runner never sees the disconnect. Its serial commandExecutionQueue runs the command to completion.
  • Only runner commands queue behind it. A next request whose device work skips the runner, such as a simctl launch from open --relaunch, simctl privacy, or a screenshot, can overtake the tap. So can the runner's inline status and uptime.

Android holds the lock until adb returns, so it is serialized already.

Consumer impact: tester-army/e2e cannot adopt signal. It keeps an inflight set of abandoned commands and waits for each response before the next attempt starts, so that a tap from a canceled step cannot land in the retry (packages/mobile/src/surface.ts). With signal, the client's promise rejects immediately, so that wait no longer proves the device finished.

Required behavior

  • A canceled request whose runner command was already sent keeps its session and device locks until the runner reports that command terminal (completed or failed in the command journal), or until the command's own deadline expires. The client still rejects at once with request_canceled.
  • A command that never reached the runner, or one the runner refused, releases at once, as it does today.
  • A drain that hits the deadline leaves the charge abandoned, as today, so the detach/handoff rules keep seeing it.

Done when

  • A test shows that a canceled runner command holds the session lock until the runner journal reports it terminal, and that a second request on the session starts only after that.
  • Live on an iOS simulator: abort a long press (or longpress --duration) through the client, then immediately run open --relaunch. The launch starts after the press finishes, as the request log shows.

Related: #3178 (per-call signal), #2965 (charge settlement by terminal evidence).

主要言語
TypeScript
スター
4.9k
フォーク
328
平均マージ
12時間 18分
マージ済み PR（30日）
561

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

callstack/agent-device のほかの issue

callstack/agent-device の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。