fix: client: transport start failed will make listTools stuck #72

[iptton]

transport may be closed before send message, it should throw exception by Transport#sendMessage instead failed silently with safety call

Motivation and Context

transport may be closed before send message, it should throw exception by Transport#sendMessage instead failed silently with safety call otherwise , result.await() will never return

How Has This Been Tested?

it should be test by ClientTest.kt, but that may not necessary. it will happen when transport closed at the point withTimeout called, it's hard to simulate that case but you can remote the val transport = [email protected] ?: throw .... to simulate it...

@Test
    fun `should throw exception when transport closed before call list`() = runTest(timeout = 10.seconds) {
        val serverOptions = ServerOptions(
            capabilities = ServerCapabilities(
                resources = ServerCapabilities.Resources(null, null),
                tools = ServerCapabilities.Tools(null)
            )
        )
        val server = Server(
            Implementation(name = "test server", version = "1.0"),
            serverOptions
        )

        server.setRequestHandler<InitializeRequest>(Method.Defined.Initialize) { request, _ ->
            InitializeResult(
                protocolVersion = LATEST_PROTOCOL_VERSION,
                capabilities = ServerCapabilities(
                    resources = ServerCapabilities.Resources(null, null),
                    tools = ServerCapabilities.Tools(null)
                ),
                serverInfo = Implementation(name = "test", version = "1.0")
            )
        }

        server.setRequestHandler<ListResourcesRequest>(Method.Defined.ResourcesList) { request, _ ->
            ListResourcesResult(resources = emptyList(), nextCursor = null)
        }

        server.setRequestHandler<ListToolsRequest>(Method.Defined.ToolsList) { request, _ ->
            ListToolsResult(tools = emptyList(), nextCursor = null)
        }

        val (clientTransport, serverTransport) = InMemoryTransport.createLinkedPair()

        val client = Client(
            clientInfo = Implementation(name = "test client", version = "1.0"),
            options = ClientOptions(
                capabilities = ClientCapabilities(sampling = EmptyJsonObject),
            )
        )

        listOf(
            launch {
                client.connect(clientTransport)
            },
            launch {
                server.connect(serverTransport)
            }
        ).joinAll()

        // Server supports resources and tools, but not prompts
        val caps = client.serverCapabilities
        assertEquals(ServerCapabilities.Resources(null, null), caps?.resources)
        assertEquals(ServerCapabilities.Tools(null), caps?.tools)
        assertTrue(caps?.prompts == null) // or check that prompts are absent

        // simulate transport closed before get resource or tool list
        // this may happen when transport config incorrectly
        clientTransport.close()

        // These should not throw
        client.listResources()
        client.listTools()

        // This should fail because prompts are not supported
        val ex = assertFailsWith<IllegalStateException> {
            client.listPrompts()
        }
        assertTrue(ex.message?.contains("Server does not support prompts") == true)
    }

Breaking Changes

NO

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[Copilot]

Pull Request Overview

This PR fixes an issue in which a closed transport causes listTools to hang by ensuring that an exception is thrown when sending a message on a closed transport.

• Removed the safety call operator on the transport when sending a message
• Allowing a thrown exception (or NPE) to occur instead of silently ignoring the call

[Copilot]

While the change ensures an exception is thrown when transport is closed, consider explicitly checking if transport is non-null and throwing a descriptive exception such as IllegalStateException to improve clarity when transport is unexpectedly null.

Suggested change

	transport.send(message)
	transport?.send(message) ?: throw IllegalStateException("Transport became null unexpectedly while sending the message")

[e5l]

could you add the test in the codebase?