Repository navigation
MCP errors pass unbounded through a worker #187
Description
Activity
- changed the title
[-]MCP Errors pass unbounded through a worker - land untrunicated in the parent coordinator artifacts[/-][+]MCP errors pass unbounded through a worker[/+]on Jun 4, 2026 - added a parent issue
on Jun 10, 2026 - added a commit that references this issue
on Jun 10, 2026 #247 addressed number 1 of this
We may want to split the second part of this into two:
- Leverage progress notifications for those MCP's which do support progress notifications
- Improve experience when using MCP's which do not have progress notifications
@justintime4tea we should verify where this is still broken if at all
@gjanco this bug is verify (see above) + split into a subticket the section that isn't done yet - I think @justintime4tea already did most of this
Problem
Diagnosing a noisy panic on the MCP server I noticed two bad failure patterns.
A large 50k unbounded stack trace got passed to the continuation prompt in the coordinator. This blows up the coordinator context window, throwing it into a short replan loop before timing out. We already handled similar constraints in bug(orchestration): large tool outputs overflow LLM context when scratchpad is disabled #120 but that only helps at the coordinator level.
This particular call waited until just about the end of the 15min timeout before it threw an error. It's really hard to tell the difference between a long running MCP call and a stuck open port. For long running tools that also have progress notifications we could experiment with a configurable "first notification" timeout to catch stuck processes early and fail gracefully.