What cancellation contract should MCP client factories guarantee?

[PierrunoYT]

Contract question

internal/mcp/registry.go starts each configured server concurrently. It calls the pluggable client factory in a goroutine, returns a timeout result when the configured duration expires, cancels that server context, and starts a background reaper waiting for the factory result so any late client can be closed.

This works for current built-in factories that honor context cancellation. If a custom/test/plugin-supplied factory ignores context forever, both the factory call and its reaper remain blocked after startup has moved on. The leak is bounded per timed-out attempt, but there is no independent way for the registry to terminate work it does not own.

Audit context: finding CON-01 at main revision 1b5db1765672820caac1684b168c9898b5ba3593, primarily internal/mcp/registry.go around lines 115-143.

No leak from a current built-in MCP transport was reproduced, so this is a contract/ownership question rather than a bug report.

Existing strengths

• startup I/O is concurrent while validation/registration is committed deterministically in server order;
• every built-in connection gets a derived context and cancellation;
• late successful clients are closed by the reaper;
• one slow server does not block all registration; and
• current full race testing reports no memory race.

These properties should remain.

Options

1. Document and test a strict factory contract: factory implementations must return promptly after ctx.Done(). Add a context-ignoring fake to define expected diagnostics, but accept that Go cannot force-stop a violating goroutine.
2. Return an independently closable attempt handle: the registry can close the underlying process/transport even if factory orchestration is stuck. This enlarges the interface and only helps if acquisition exposes ownership early enough.
3. Move timeout ownership into each transport factory: built-ins and extensions must implement a bounded connect method; the registry stays simpler but conformance still needs tests.
4. Out-of-process isolation for untrusted factories: likely disproportionate unless factories become a public untrusted extension boundary.

Questions for maintainers

• Are custom factory implementations a supported extension contract or only an internal test seam?
• Is context compliance sufficient, or must the registry guarantee no retained goroutine despite a violating implementation?
• Should timeout errors identify the server and expose a bounded diagnostic without transport secrets?
• Would an interface change be worth the compatibility cost, or should the existing contract simply become explicit and tested?

Any implementation should preserve deterministic registration, best-effort startup, bounded stderr/output, cancellation of built-ins, and race coverage.

Full audit detail: https://github.com/PierrunoYT/zero/blob/audit/codebase-audit-2026-09-08/docs/audit/CONCURRENCY_AUDIT.md#con-01--mcp-timeout-may-leave-a-goroutine-if-a-factory-ignores-context