[Client] HttpTransport resumes an Amp-suspended Fiber with a JSON-RPC error

Describe the bug

HTTP MCP initialization fails with a type error when the HTTP request uses Amp:

HTTP request failed: Amp\Internal\FutureIterator::consume(): Return value must be of type ?array, Mcp\Schema\JsonRpc\Error returned

The suspected cause is competing ownership of the same Fiber. HttpTransport::processFiber() checks whether the active Fiber is suspended, then resumes it with a JSON-RPC response or timeout error. However, an Amp-backed PSR-18 client can suspend that Fiber during sendRequest(), before the SDK reaches its own response wait. The timeout error then reaches Amp's suspension instead of the SDK's response wait.

To Reproduce

Observed in a CLI application using mcp/sdk v0.7.1, with HTTP client discovery left enabled. Three separate HTTP MCP servers fail during initialization, each after approximately 30 seconds.

Steps to isolate the suspected integration conflict:

1. Use the SDK HTTP transport with Symfony's Psr18Client, explicitly backed by AmpHttpClient, so backend selection does not depend on the host's cURL capabilities.
2. Configure an HTTP MCP endpoint and an initialization timeout.
3. Connect through the SDK client.
4. Observe whether the SDK resumes the Fiber while Amp is waiting for HTTP I/O, causing the type error above when the initialization timeout expires.

These isolation steps are proposed, not a separately executed minimal reproduction. The application failure and logs below are observed. We have not yet reproduced the failure with an explicitly injected Amp client or rerun it on v0.8.1.

Expected behavior

The HTTP transport must not resume a Fiber suspended by the injected HTTP client. Initialization should complete, or fail with the relevant transport or initialization error, without passing a JSON-RPC object into Amp's internal suspension.

If Fiber-suspending PSR-18 clients are unsupported, that restriction should be documented and enforced rather than failing with an unrelated return-type error.

Logs

Sanitized excerpts from the same application session on 2026-09-09. Each failure was for a different HTTP MCP server:

21:55:26.003694Z MCP server discovery failed
HTTP request failed: Amp\Internal\FutureIterator::consume(): Return value must be of type ?array, Mcp\Schema\JsonRpc\Error returned

21:55:56.000764Z MCP server discovery failed
HTTP request failed: Amp\Internal\FutureIterator::consume(): Return value must be of type ?array, Mcp\Schema\JsonRpc\Error returned

21:56:26.000375Z MCP server discovery failed
HTTP request failed: Amp\Internal\FutureIterator::consume(): Return value must be of type ?array, Mcp\Schema\JsonRpc\Error returned

Additional context

Application dependency lock:

• mcp/sdk: v0.7.1, commit 785fc3b9b7006ecc8a73322c939d96a4a7154345
• symfony/http-client: v8.1.5
• amphp/amp: v3.1.3
• amphp/http-client: v5.3.6
• revolt/event-loop: v1.0.9

Relevant source:

• SDK v0.7.1 HttpTransport: connect() starts an active Fiber. send() calls the PSR-18 client inside it. processFiber() resumes the active Fiber with a JSON-RPC error when a pending request times out.
• Amp v3.1.3 FutureIterator: consume(): ?array returns the value supplied to its event-loop suspension. Receiving an MCP error object here matches the observed exception.
• SDK v0.8.1 HttpTransport: source inspection shows the same unconditional resume of a suspended active Fiber. The same logic was also present on main when checked on 2026-09-09. This is source evidence, not a runtime reproduction on those revisions.

Explicitly injecting Symfony's Psr18Client backed by CurlHttpClient is a proposed application workaround. It has not yet been validated for this failure. It would avoid the Amp path but would not fix Fiber ownership in the SDK.

A search of upstream issues and PRs for Amp, amphp, FutureIterator, and fiber did not find a matching report. PR #425 addresses HTTP status handling, not this suspension conflict.

Beginne in src/Client/Transport/HttpTransport.php und verfolge connect(), send() und processFiber(), und vergleiche dann das in dem Bericht beschriebene Verhalten von v0.7.1, v0.8.1 und main. Reproduziere das Problem mit einem explizit injizierten Amp-basierten PSR-18-Client und einem Initialisierungs-Timeout. Erledigt ist die Aufgabe, wenn von Amp suspendierte Fibers nicht mit MCP-Fehlern fortgesetzt werden oder nicht unterstützte Clients dokumentiert und mit einem relevanten Fehler abgelehnt werden.