Desktop boot: show window immediately, self-heal stale launchd state, fix boot-path latency#1303
Merged
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
executor-marketing | 12e7d75 | Commit Preview URL Branch Preview URL |
Jul 04 2026, 05:38 AM |
Contributor
Cloudflare previewTorn down — the PR is closed. |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
executor-cloud | 12e7d75 | Jul 04 2026, 05:38 AM |
@executor-js/cli
@executor-js/config
@executor-js/execution
@executor-js/sdk
@executor-js/plugin-file-secrets
@executor-js/plugin-graphql
@executor-js/plugin-keychain
@executor-js/plugin-mcp
@executor-js/plugin-onepassword
@executor-js/plugin-openapi
@executor-js/codemode-core
@executor-js/runtime-quickjs
executor
commit: |
RhysSullivan
force-pushed
the
rs/e2e-stale-launchd-repro
branch
from
c433090 to
13eca55
Compare
RhysSullivan
force-pushed
the
rs/desktop-boot-fixes
branch
from
22ac04e to
4121d9a
Compare
This was referenced Jul 4, 2026
…tate Two boot-time fixes in the desktop main process: Show a lightweight "Starting Executor" window at app.whenReady, before any service or sidecar work, then load the real web UI into the same window once the connection resolves (no second-window flash). A pending second-instance now focuses that startup window instead of no-opping while connection is null. Classify the supervised service by both registered and running instead of ignoring the running signal: - registered and running: attach; only kick if the attach still misses it. - registered but not running (the stale plist/unit/task case): restart, and if the OS manager cannot start it, reinstall the service (install is already idempotent) before waiting. If install also fails, fall back to managed spawn immediately. The 15s attach wait is only paid after a kick or install actually succeeds, so a stale registration no longer costs a dead wait.
captureUserPath shells out to $SHELL -ilc on every bundled-executor call, including read-only `service status` that boot runs first. Skip the capture for `service status` (process env PATH is enough for a read) and memoize it for the rest of the process lifetime so install/restart pay the shell probe at most once instead of on every call.
The repro pinned the broken behavior (stale plist forces a >=14s dead wait). Flip it to guard the fix: the startup window must appear within a few seconds, the kickstart failure must be followed by a self-heal-or-fallback log line rather than a dead wait, boot-to-ready must stay under the fast budget and close to the clean control, and recovery must either repair launchd or fall back cleanly to managed spawn without attaching to the stale plist port. The E2E_RECORD recording now captures the fixed fast boot.
RhysSullivan
force-pushed
the
rs/desktop-boot-fixes
branch
from
4121d9a to
12e7d75
Compare
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.
Incident
A plist can exist at
~/Library/LaunchAgents/sh.executor.daemon.plistwhile the service is not loaded in launchd. On boot the desktop app paid a failinglaunchctl kickstartand then a deadwaitForSupervisedAttach(15_000)before falling back to managed spawn, and the window was only created after a connection resolved. Users saw a menu bar and no window for ~17s on every boot. Separately, login-shell PATH capture ($SHELL -ilc, 5s timeout) ran on every bundled-CLI call, including the read-onlyservice statuson the boot path.Fixes
app.whenReady(), before any service/sidecar work; the real web UI loads into the same window (no second-window flash).second-instancenow focuses the startup window while the connection is still pending.RegisteredandRunningfromservice statusinstead of ignoringRunning:service restart; if the OS manager cannot start it, reinstall the service (install is idempotent bootout/enable/bootstrap); if that also fails, fall back to managed spawn immediately. The 15s attach wait is only paid after a kick or install actually succeeds.service statusno longer captures the login-shell PATH, and the capture is memoized so install/restart pay it at most once per process.e2e/desktop-packaged/stale-launchd-registration.test.tsnow guards the fixed behavior (startup window < 3s, stale boot < 10s and close to the clean control, kickstart failure followed by self-heal-or-fallback logging, recovery never attaches to the stale plist port).Verification (all behavioral runs in VMs; nothing was launched on the dev host)
vitest run --project desktop-macos(packaged bundle pushed into guest, driven over CDP)vitest run --project desktop-linuxservice status,service restartin-guestRegistered: yes / Running: nowhen stopped; restart brings it back to runningapps/cli/src/service.test.ts(18/18)bun run typecheck,lint,format:checkMeasured durations (macOS guest)
In-guest log lines from the stale boot (the self-heal path, no dead wait):
(In a tart guest the
launchctl asusersession fails the kickstart with exit 125 instead of production's exit 113; the test matches the desktop's own classification line so it holds in both environments.)Recording of the stale-plist boot in the guest (window up in under 2s):
e2e/recordings/stale-launchd-fast-boot.mp4(440KB, 12s), replacing the old slow-boot recording.Gaps
desktop-linuxboots the packaged app against a supervised daemon.Stack