[crossxr]

On stdio transports, a handshake-era server may silently ignore server/discover, which the stdio spec permits. Connect then blocked until the caller's context expired and never reached the initialize fallback, which reused the same expired context.

Connect now bounds the discover probe when the transport's connection is a newline-delimited stream connection. That covers CommandTransport, IOTransport, StdioTransport and InMemoryTransport, including through LoggingTransport or a custom transport that returns the inner connection. The bound is set by the new ClientSessionOptions.DiscoverTimeout: 10s by default, disabled by a negative value, and never more than half of the caller's remaining deadline. On timeout Connect falls back to initialize as for any other discover error. HTTP transports are unchanged.

A modern stdio server that answers discover only after the probe times out still connects through initialize, so it gets the 2025-11-25 protocol. Its late discover reply is dropped.

Fixes #1332

[soyeladice-svg]

One edge case appears to leave the original silent-stdio hang intact for custom/wrapped transports.

discoverProbeContext enables the timeout only when isStdioTransport(t) recognizes *CommandTransport, *IOTransport, *StdioTransport, or recursively *LoggingTransport. But Transport is a public interface and the SDK docs explicitly support custom transports. A user-defined decorator around an IOTransport/stdio transport therefore fails the type switch and receives the unbounded discovery context; against a handshake-era server that silently ignores server/discover, Connect can still wait indefinitely.

This is especially easy to hit for instrumentation/filtering wrappers (the codebase already has precedent for wrapped transport/connection types). Could stdio/discover-timeout capability be preserved through a small optional interface/marker, or otherwise made wrapper-safe, instead of relying only on the concrete outer transport type?

A regression can wrap the same silent IOTransport fixture in a custom Transport delegator and assert that fallback still occurs within the configured probe timeout.

AI assistance was used to inspect the patch; no acceptance/merge claim is implied.

[crossxr]

Thanks, good catch. I switched the check from the transport type to the connection it returns. The probe is now bounded whenever the connection is a newline-delimited stream connection (*ioConn, including through LoggingTransport). That covers stdio, IO and in-memory transports, plus any custom transport that delegates and returns the inner connection. I added your suggested regression test, which wraps the silent IOTransport in a custom delegating Transport.

A wrapper that also wraps the Connection still won't be detected. Covering that would need an exported interface, which seems better as a separate proposal if there's interest.