rossoctl / rossoctl/workload-harness

fix: MCP session not cleaned up gracefully on timeout

Open
#30 1 comment 0 reactions 0 assignees View on GitHub

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.Session span is marked ERROR due to the cleanup failure, conflating two distinct failure modes (agent timeout vs. infrastructure error) in trace analysis.
  • A second MCP.DeleteSession call is attempted and silently succeeds (status UNSET), 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.DeleteSession should 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.DeleteSession is called (or skipped safely) before killing the sidecar process.
  • The Agent.Session span'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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.