rossoctl / rossoctl/workload-harness
fix: MCP session not cleaned up gracefully on timeout
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 5
- Forks
- 6
- Avg merge
- 11h 37m
- Merged PRs (30d)
- 1
Description
Summary
When an agent session times out, the MCP sidecar process is killed before the harness has a chance to call MCP.DeleteSession, resulting in an error during cleanup and a non-graceful session teardown.
Observed Behavior
In trace tr-6635ef947049886b3b143e621b508cab (TAU2, tool_calling, Qwen3.6-35B-A3B), the MCP.DeleteSession span errors with:
RuntimeError: Session deletion failed: Session deletion failed:
{'error': 'Error closing session 5788bd81-33f1-471b-9ec2-c75a9110bd02:
Service at http://127.0.0.1:59685 is no longer alive'}
The session output is "Session completed (timeout)", meaning the MCP process was already dead when the harness tried to tear it down.
The Agent.Session span inherits this as its top-level error status, making the trace appear as ERROR even though the primary failure was the agent timeout — not a crash.
Impact
- Session cleanup leaves resources in an indeterminate state.
- The
Agent.Sessionspan is markedERRORdue to the cleanup failure, conflating two distinct failure modes (agent timeout vs. infrastructure error) in trace analysis. - A second
MCP.DeleteSessioncall is attempted and silently succeeds (statusUNSET), indicating a retry path exists but the first attempt's error still propagates up.
Root Cause
The MCP sidecar at the local address (127.0.0.1:<port>) is terminated as part of the timeout handling before MCP.DeleteSession is invoked. The delete call then hits a dead socket.
Expected Behavior
MCP.DeleteSessionshould check whether the session/process is still alive before attempting to close it, and handle the "already dead" case as a clean no-op (or at most a warning), not an error.- Alternatively, the timeout handler should ensure
MCP.DeleteSessionis called (or skipped safely) before killing the sidecar process. - The
Agent.Sessionspan's error status should reflect the agent-level outcome (timeout), not a cleanup side-effect.
Trace Reference
- Trace ID:
tr-6635ef947049886b3b143e621b508cab - Benchmark:
tau2 - Agent:
tool_calling - Model:
openai/Qwen3.6-35B-A3B - Session ID:
5788bd81-33f1-471b-9ec2-c75a9110bd02
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the timeout handler, MCP.DeleteSession, and the Agent.Session span cleanup path to confirm where the sidecar is terminated. Verify the fix with the referenced timeout trace or an equivalent session, ensuring a dead sidecar does not turn cleanup into an error or mark the agent span as failed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- shell
- Domain
- backend, observability
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100