iOS: a canceled request releases the session lock while its runner command still runs on the device
Maintainer antworten meist innerhalb von 1 Tag
Ein zugehöriger Pull Request wurde bereits gemerged.
- #3385 von @thymikee — gemerged
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 22/100
- Issue-Typ
- Bug
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- ios, typescript
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
fetchrejects 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
commandExecutionQueueruns the command to completion. - Only runner commands queue behind it. A next request whose device work skips the runner, such as a
simctl launchfromopen --relaunch,simctl privacy, or a screenshot, can overtake the tap. So can the runner's inlinestatusanduptime.
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 (
completedorfailedin the command journal), or until the command's own deadline expires. The client still rejects at once withrequest_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(orlongpress --duration) through the client, then immediately runopen --relaunch. The launch starts after the press finishes, as the request log shows.
Related: #3178 (per-call signal), #2965 (charge settlement by terminal evidence).
- Vorherrschende Sprache
- TypeScript
- Sterne
- 5.2k
- Forks
- 359
- Ø Merge
- 12 Std. 54 Min.
- Gemergte PRs (30 T.)
- 637
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus callstack/agent-device
-
bug ready-for-agent
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 77/100
callstack/agent-device#4018 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
callstack/agent-device#3945 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Limrun iOS fill reports success but drops non-ASCII textEvtl. vergeben @mvanhorn hat das vor 8 Tagen übernommen. Offenbug ready-for-agent
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 87/100
callstack/agent-device#3819 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
callstack/agent-device#1869 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Android snapshot helper: a capture cancelled in its first milliseconds stalls the next captureOffenbug ready-for-agent
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 72/100
callstack/agent-device#4030 ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in callstack/agent-device
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
Graphify-Labs/graphify#4860 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
sveltejs/eslint-plugin-svelte#1615 ·
Maintainer antworten meist innerhalb von 7 Tagen
-
Parallel reticle_verify opens per-flow leases without the source lease's ignoreHTTPSErrorsEvtl. vergeben @as992949791 hat das heute übernommen. Offengood first issue help wanted
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
reticlehq/reticle#2033 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag