Repository navigation
[BUG]: most SSE event fields aren't size-capped #232
Description
Activity
- added a parent issue
on Jun 11, 2026 Vetted 2026-07-17 on main. Three fields are truncated via tool_result_max_length (default 1000): the success results on tool_complete, task_completed, and tool_call_completed. Roughly ten remain unbounded, including tool_complete's error path (err.full_message()), reasoning, worker_reasoning, planning_response, both tool-argument fields, and progress.message (which is MCP-server controlled, so effectively hostile input). PR #124 does not cover any of this: its 64KB cap lives in the OTel exporter, a different pipeline. The unified bounding work on the card/S* branches has not landed. Description updated with the field census.
- changed the title
[-]Unbounded SSE field truncation[/-][+][BUG]: most SSE event fields aren't size-capped[/+]on Jul 17, 2026
Three SSE fields are truncated today, all via tool_result_max_length (default 1000): the success results on tool_complete, task_completed, and tool_call_completed (streaming/handlers.rs:950,1154,1272). Roughly ten ship unbounded as of 2026-07-17: tool_complete's error path (err.full_message(), :944), reasoning (:1029), worker_reasoning (:1215), planning_response (:1087), direct_answer, clarification, iteration_complete.reasoning, both tool-argument fields (:253,:1249), and progress.message (:221), which is MCP-server controlled, so effectively hostile input.
PR #124 is sometimes cited as fixing this. It does not; its 64KB cap lives in the OTel exporter, a different pipeline. The unified bounding work on the card/S* branches has not landed on main. Related: #187 is the same unbounded-content problem at the coordinator-prompt layer.