Repository navigation
Conversation
|
The following comment was made by an LLM, it may be inaccurate: |
There was a problem hiding this comment.
This fixes the startup kill-and-respawn loop inside a single ensure() call. I ran the real Promise ensure() against a stand-in service that registers right away and then answers /api/info only after 15s. On the base it spawned 20 contenders, killed 19 as unresponsive and timed out after 120s. With this PR it spawned one and was ready in 15s. Both service test files pass (45), the client typecheck passes, and your changed tests fail on the base as expected.
Public API: unchanged (starting() is on the internal contender pool only).
Worth knowing, though not blocking:
- Only the
ensure()call that spawned the contender protects it. Any other client starting at the same time (a second terminal, or the desktop app alongside the CLI) still evicts the service after three probe timeouts (about 6s). A cold start longer than the 120s deadline (#54810 reports up to about 6 minutes) still makesensure()give up, and the next launch, which doesn't own the process, kills it. So #54810's loop gets shorter but can still happen on very slow stores. - A contender that registers and then truly hangs now costs the full 120s and stays registered, where before it was replaced within seconds. That matches the existing "never killed merely for slow startup" rule, and the next launch recovers it. It's still a change users with a wedged startup will notice.
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Issue for this PR
Related to #54810 (the probe-driven startup retry loop).
Type of change
What does this PR do?
Let live, registered service contenders spawned by
ensure()use its existing startup deadline instead of killing them after three short health-probe timeouts. Once an owned contender registers, stop recruiting additional contenders while it initializes.The wait stays bounded by the existing 120-second timeout. This addresses the retry loop; the issue’s database migration cost and HDD performance are separate work.
How did you verify your code works?
Cannot find module aws4fetch. Astro’s blocked Wrangler log writes also produced environment warnings.Screenshots / recordings
No UI change.
Checklist
Added by the opencode bot (AI-generated).
Related: #54810, #51216, #54181