Task goroutine context is canceled when HTTP response is flushed (executeRegularToolAsTask) #897

Activity

1. mark-iii-labs-huly commented on May 28, 2026

   

   mark-iii-labs-hulybot

   on May 28, 2026 – with Mark III Labs - Huly

   More actions

   Connected to Huly®: MCP_G-462
2. jhonsferg commented on Jul 13, 2026

   

   jhonsferg

   on Jul 13, 2026

   Last edited by jhonsferg

   More actions

   Ran into this independently while building an MCP server on top of mark3labs/mcp-go v0.56.0 - wanted to add a data point since the reproduction here happens over stdio, not just streamable HTTP, which changes the root-cause story a bit.

   Reproducing over stdio

   Registered a plain tool via AddTool + mcp.WithTaskSupport(mcp.TaskSupportOptional), enabled WithTaskCapabilities(true, true, true), and drove it over ServeStdio with raw JSON-RPC (no HTTP transport in the picture at all). Sending tools/call with a task param behaves exactly as described here: CreateTaskResult comes back immediately with status: "working", a notifications/tasks/status "completed" notification follows within milliseconds, and tasks/result then reports the handler's own error - context canceled - before any real work (an outbound HTTP call in my case) had a chance to finish.

   Where it actually comes from

   Since there's no net/http request in this path, it can't be r.Context() getting cancelled on response flush. Tracing it through request_handler.go:

   // HandleMessage
   ctx, cancel := context.WithCancel(ctx)
   defer cancel()
   if baseMessage.ID != nil {
       key := inflightKey(ctx, baseMessage.ID)
       s.inflightCancels.Store(key, cancel)
       defer s.inflightCancels.Delete(key)
   }

   This wrapper exists to support notifications/cancelled for normal (non-task) calls, and it's harmless there since the handler runs to completion before HandleMessage returns. But for a task-augmented call, handleToolCall -> handleTaskAugmentedToolCall launches go s.executeRegularToolAsTask(ctx, ...) and then returns immediately so HandleMessage can send the CreateTaskResult response, which fires this defer cancel() right as (or before) the spawned goroutine's own context.WithCancel(ctx) gets a chance to observe a still-live parent.

   So the cancellation source here is transport-agnostic: it's HandleMessage's own inflight-cancellation bookkeeping, not something specific to the HTTP transport's request lifecycle. Streamable HTTP just happens to be the transport where people noticed it first, likely because r.Context() cancellation is a more familiar shape of this class of bug.

   On the fix in #900

   context.WithoutCancel(ctx) at the executeTaskTool/executeRegularToolAsTask boundary is the right fix regardless of which ancestor is doing the cancelling, since it detaches from cancellation propagation from any parent, not just an HTTP request context - so it should close this stdio case too once merged. Happy to help verify against the stdio repro if useful.