fix: bound devicectl calls with a timeout + cache the iOS app list#19
Merged
Conversation
Jaca polls `devicectl list devices` on the discovery loop and runs `device info apps` for the app picker, but CommandRunner had no timeout. When CoreDevice stalls (common with devicectl), those calls hang forever and pile up zombie processes -- which wedges CoreDevice further, so `device info apps` then times out and the iOS app picker shows "No apps found on this device". - CommandRunner.run gains an optional `timeout` that SIGKILLs a wedged child, so a hung tool can't block the call or accumulate. Applied to every devicectl site: list devices (discovery poll), info apps, lockState poll, and the device-availability checks. - The iOS app list is cached to disk per device; a slow/empty/failed query falls back to the last good list so the picker never blanks while devicectl flakes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
DevSrSouza
added a commit
that referenced
this pull request
Jun 17, 2026
Building on the devicectl timeout + cache (#19), make the picker resilient to a slow/flaky devicectl instead of just bounding it: - Retry the `device info apps` query once. devicectl's first call after a cold start often stalls warming the tunnel, then the retry returns fast — so a single transient timeout no longer drops to an empty list. - Cache-first: show the last good list instantly while a refresh runs, and keep it shown if the refresh fails — no blank "No apps found" flash when we have a cache. - Reopening the picker re-fetches whenever the list is empty, and the empty state now has a Retry button — so a wedged-then-recovered devicectl is one click (or reopen) away from populating. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The iOS-device app picker shows "No apps found on this device" even though the apps are installed.
Root cause is a robustness gap, surfaced by
devicectlbeing flaky (CoreDevice stalls):devicectl list deviceson the discovery loop and runsdevicectl device info appsfor the picker — butCommandRunner.runhad no timeout.devicectlwedges, those calls hang forever and pile up zombie processes (observed 5+ stucklist devicesat once). That congestion wedges CoreDevice further, sodevice info appsthen times out and the picker comes back empty.Fix
CommandRunner.run— an optionaltimeoutSIGKILLs a child that runs too long, so a hung tool can't block the call or accumulate. Applied to everydevicectlsite:list devices(discovery poll, 12s),device info apps(25s),lockStatepoll (8s), and the device-availability checks (12s).devicectlflakes.Notes
🤖 Generated with Claude Code