Repository navigation
fix(core): start newly added MCP servers in the background - #53813
Open
opencode-agent[bot] wants to merge 2 commits into
Open
opencode-agent[bot] wants to merge 2 commits into
opencode-agent[bot] wants to merge 2 commits into
Conversation
The guarded early plugin activation from #53775 runs the first MCP reconcile before config MCP servers are registered. Servers added on a later reconcile then went through the replace path, which connects them one at a time while the plugin activation batch waits, so providers and integrations did not appear until the slowest server finished starting. Start every server that is new to the reconcile in the background, and keep an explicit MCP.add waiting for its own server to settle.
A server removed or replaced before its background start acquired the per-server lock was still started from its stale entry, leaving an untracked process running until the Location closed.
3 of 6 tasks
This branch has not been deployed
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
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.
Issue for this PR
Regression from #53775.
Type of change
What does this PR do?
Since #53775, a slow MCP server delays startup: models and
/connectstay empty until every configured MCP server has connected, and the servers connect one after another instead of in parallel.Cause: the supervisor now activates the guarded plugins (
OpencodePlugin,ConfigPolicyPlugin) first. Both registerctx.mcp.transform, so MCP's first reconcile runs before the config MCP plugin has added any servers.Mcponly started servers in the background on that first reconcile (!applied && entries.size === 0). The config servers arrive on a later reconcile and go throughreplaceServer, which awaitsstartServerfor each server in turn. That happens inside the plugin activation batch's notify, so the rest of plugin activation waits for it.Fix: any server that is new to the reconcile now starts in the background. The special first-reconcile branch is removed, so new servers take the same path whether they arrive first or later. Readers still wait on each entry's startup latch. Config changes to existing servers still replace them synchronously, as before.
MCP.add(HTTP API, ACP session MCPs) now waits for its own server's startup latch, so it still returns once that server has settled.A background start now checks that its entry is still current once it holds the per-server lock. Without that check, a server removed or replaced before its start ran was still spawned from the stale entry and kept running, untracked, until the Location closed. The first-reconcile path on
v2used the same fork pattern without this check.Remote endpoint startup is still serialized per URL (
endpointLoads), because that lock lives insidestartServer.How did you verify your code works?
servein a clean HOME with two stdio MCP servers that each take 5s to start, pollingmodel.list,integration.listand/api/mcp:b8d3c92985): models at ~2.1s, both MCPs connected at ~7sv2: first response at ~12.2s, MCPs connected one after anotherdoes not wait for MCP servers added after the first reconcile to start: fails on currentv2(the transform hangs) and passes heredoes not start an MCP server removed before its background start: fails without the stale-entry check, passes with itmanages live MCP servers entirely through scoped transforms, which asserted that a newly added server was already connected when its transform returned (the blocking behavior); it now waits for the server to settlebun test test/mcp.test.ts(80 pass); MCP, plugin andtest/plugin/suites (435 pass);bun run typecheckinpackages/coreScreenshots / recordings
N/A
Checklist
Requested by: @neriousy (Filip via Slack)