Skip to content

fix(client): preserve initializing service contenders - #54883

Closed
Dante-dan wants to merge 1 commit into
anomalyco:devfrom
Dante-dan:slow-start-readiness
Closed

Dante-dan wants to merge 1 commit into
anomalyco:devfrom
Dante-dan:slow-start-readiness

Conversation

@Dante-dan

@Dante-dan Dante-dan commented Oct 12, 2026 •

Copy link
Copy Markdown
Contributor

Issue for this PR

Related to #54810 (the probe-driven startup retry loop).

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

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?

  • 51 existing service lifecycle tests passed, including delayed-health startup for Promise/Effect clients, bounded startup failure reporting, and unresponsive incumbent recovery.
  • Client typecheck passed; root lint and SDK documentation checks passed with warnings and no errors.
  • Full workspace typechecks (telemetry disabled, Turbo loose environment) stopped at an unrelated console-app missing dependency: Cannot find module aws4fetch. Astro’s blocked Wrangler log writes also produced environment warnings.
  • The original Windows HDD/store scenario was not reproduced locally.

Screenshots / recordings

No UI change.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

Added by the opencode bot (AI-generated).

Related: #54810, #51216, #54181

@github-actions

Copy link
Copy Markdown
Contributor

The following comment was made by an LLM, it may be inaccurate:

@opencode-agent opencode-agent Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 makes ensure() 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.

Related: #54810, #51216, #54181

@github-actions

Copy link
Copy Markdown
Contributor

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:

  • The PR was created more than 1 month ago
  • The PR had fewer than 2 positive reactions
  • Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant