Repository navigation
Conversation
…dead process A restart or crash leaves the service registration behind. ensure() gave every unanswered registration a 5 s spawn delay before starting a replacement, so the first launch after each reboot waited for a process that no longer exists. The delay now applies only while the registered process is running; only ESRCH counts as gone, so a live process the client cannot signal still gets the delay.
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
Looks good. I reproduced the stale-registration wait on the base: with a service.json naming an exited PID, ensure() waited about 5 s before spawning a replacement. With this change it spawned in about 3 ms. The contender pool, service, promise-service and effect tests pass, and so does the client type check. I didn't run the desktop app or test on Windows, so the EPERM and reused-PID cases are checked by reading the code only.
Public API: unchanged. shouldRecruit is internal to service-contender.ts and not exported from the package.
No concerns.
|
AI-assisted supplemental verification of Six public-client cases pass on head; the same cases with base sources give four passes and two failures. For both Promise and Effect The contender-pool, Effect API and supplemental files pass 21 tests after restoring head. A separate run of the three owning lifecycle files gives the same 44 passes / 4 skips / 3 failures on both revisions: prepared handoff, overlapping-failure timing, and the stalled-survivor deadline. This is not an all-green lifecycle result. Client typecheck is blocked here by the native compiler's Dependencies were borrowed from an existing local runtime; relevant Client/Schema/Protocol archive contents and the changed blobs were checked. No production code was changed. I found no additional regression in this PID-gate scope. Desktop startup, privileged reviewed and tested locally. |
A restart or crash leaves the background service's registration file (
service.json) behind.Service.ensure()gives any registration that doesn't answer a 5 sspawnDelaybefore it starts a replacement. So the first desktop launch after every reboot waits for a process that no longer exists.The delay now applies only while the registered process is still running:
info?.pidto the shared contender pool.EPERM, for example a service started as Administrator) still counts as running and keeps the delay.Impact: first desktop launch after a reboot
Desktop 2.0.29 with this change, registration left by a killed service (
bench:startup --service stale), 4 alternating launches each.On one Windows machine, 8 of the last 16 desktop launches were in this state, each waiting 5.2–7.3 s before it spawned the server.