Repository navigation
fix(service): handle unusable managed-service ports on Windows - #53355
HarshithReddyDev wants to merge 5 commits into
Conversation
… port is unbindable On Windows, the default managed-service port can fall inside an excluded TCP range (e.g. 49374 in 49292-49391): bind() fails with an EADDRINUSE-typed error while no process owns the port. After the incumbent wait expires, probe the port: a genuine collision keeps the actionable conflict error, while a refused connection relaunches on an automatically selected port and warns with the actual listening URL. Registration records the real address, so Desktop and CLI discover the running service without configuration changes.
github-actions
Bot
added
needs:issue
needs:compliance
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
|
The following comment was made by an LLM, it may be inaccurate: |
github-actions
Bot
removed
the
needs:compliance
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
|
Encountered this exact issue on Windows 11 (build 26300) with OpenCode v2.0.32 when running 'opencode plugin update' (default ports 45279/45280 rejected by the OS despite no active listener). Manually moving the service port to 12580 worked around it. Looking forward to having this dynamic fallback merged! |
|
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
Closes #52234
Type of change
What does this PR do?
On Windows, the default managed-service port
49374can fall inside an excluded TCP port range. When that happens, the service cannot bind the port even though no process owns it.The managed-service path was retrying the same unusable port instead of falling back to another available port.
This change reuses the existing available-port selection when the configured managed-service port is unbindable. The actual bound address is then used for service registration.
No Desktop-specific changes are required because Desktop already delegates managed-service startup to the CLI.
How did you verify your code works?
I reproduced the issue on Windows 11 with port
49374inside an excluded TCP range and verified that no process was listening on the port.The targeted regression test passes:
bun test --timeout 180000 test/service.test.ts -t "unbindable managed service port falls back to an available port"Result: 1 passed, 22 filtered, 0 failed, 9 expects.
The full service test suite produced 22 passing tests and one pre-existing environmental timeout unrelated to this change.
git diff --checkalso passes.Screenshots / recordings
Not applicable. This is a CLI/service logic change with no UI changes.
Checklist