You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 7497419
Browse filesBrowse the repository at this point in the historyBrowse files
fix(daemon): bound and catch the hint probe, pin the printed command
Two precision fixes from review:
- The probe was best-effort in spirit but not in fact: allowFailure only
suppresses a non-zero exit code, not a timeout or spawn-failure rejection
(exec.ts always rejects on those). listSimulatorApps' listapps call had no
timeout at all, so it could hang the error path indefinitely; the
launchctl probe had no catch, so a rejection would propagate and replace
the deterministic SESSION_NOT_FOUND with a probe failure. Threaded an
optional timeoutMs through listSimulatorApps/listSimulatorAppMetadata
(including its plutil fallback) and wrapped both
detectSoleRunningIosSimulatorApp and buildIosOpenCommandHint in try/catch
so any throw falls back to the generic hint, never propagates.
- The printed command now always pins --udid (the sole-booted-device check
only proves uniqueness within the probed device's own simulator set, not
that a fresh CLI invocation without --ios-simulator-device-set would
resolve to the same device) and echoes --ios-simulator-device-set when the
detected device carries one, so the hint is the exact command that was
live-validated, not a shorter one that happens to work by coincidence.
Added a length guard: wire-level error details are redacted before send
and silently truncate any string over 400 chars, so a hint that would
exceed a safe budget (a long device-set path pushes it there) now falls
back instead of printing a truncated, non-copy-pasteable command.
Also: "in the foreground" overclaimed what the probe verifies (a resident
but backgrounded app would match the same running-process check) — reworded
to "running".
0 commit comments