context cancelled issue after upgrading to newer version

[yash025]

We're seeing error from the mcp server, that is when the server makes any downstream http requests with context we're seeing ctx cancelled error.
The client here is langchain agent.

failed to execute HTTP request: Post "https://test.com/v1/graphql": context canceled.

It was working okay, with the older version, upgraded from 0.20 to 0.25. Also it works okay if we use ctx.WithoutCancel while making http calls.

[rwjblue-glean]

I think we'll need more info about your setup. A bunch of things landed between 0.20 and 0.25, can you try to isolate down a reproduction? That will probably either point you to what the bug is (either in mcp-go or in your code migrating from 0.20 to 0.25)...

[bailinhe]

I think it's caused by the SSEServer.handleMessage function, specifically here, where the handleMessage function will return without waiting for the go routine to finish, causing the context to be cancelled prematurely

[bailinhe]

This can be replicated by running the custom_context example in sse

curl -X POST http://localhost/message\?sessionId\=xxx \
     -H "Content-Type: application/json" \
     -d '{
        "jsonrpc": "2.0",
        "method": "tools/call",
        "id": 1,
        "params": {
            "name": "make_authenticated_request",
            "arguments": {
                "message": "hello"
            }
        }
    }'

and you should see

$ curl localhost/sse
event: endpoint
data: http://localhost/message?sessionId=xxx

event: message
data: {"jsonrpc":"2.0","id":1,"error":{"code":-32603,"message":"Get \"https://httpbin.org/anything?message=hello\": context canceled"}}

[yash025]

Nice, Thanks @bailinhe, my setup is same. Maybe while invoking handleMessage we should pass ctx which gets cancelled on session.done?

[bailinhe]

According to the godocs of the http pkg

For incoming server requests, the context is canceled when the client's connection closes, the request is canceled (with HTTP/2), or when the ServeHTTP method returns.

if we want to return 202 to the client immediately (as per #163), we likely need a separated context to be passed to the go routine

[yash025]

@bailinhe @robert-jackson-glean, please take a look at this PR: #244