ClientSessionGroup is still constrained by async with, and during session creation, it internally uses TaskGroup. This tightly couples the session lifecycle to the context scope, making it difficult to solve #922 ("Attempted to exit cancel scope") under the current design
My previous PR proposes a ClientConnectionManager (#1133) that:
Example:
s1_name = "s1_name"
s2_name = "s2_name"
s1 = StreamalbeHttpClientParams(name=s1_name, url="http://localhost:8910/mcp/")
s2 = StreamalbeHttpClientParams(name=s2_name, url="http://localhost:8910/mcp/")
m = ClientConnectionManager()
await m.connect(s1)
await m.connect(s2)
print("---session initialize---")
await m.session_initialize(s1_name)
await m.session_initialize(s2_name)
await asyncio.sleep(1)
print("---session list tools---")
res = await m.session_list_tools(s1_name)
await asyncio.sleep(1)
print("---session call tool---")
res = await m.session_call_tool(s1_name, "create_user")
print(res)
await asyncio.sleep(3)
print("---session disconnect---")
await m.disconnect(s1_name)
await m.disconnect(s1_name)
I'd appreciate any guidance on whether rewriting or replacing ClientSessionGroup would be acceptable, or if there's an alternative approach you'd suggest to address these session lifecycle limitations.
ClientSessionGroup is still constrained by async with, and during session creation, it internally uses TaskGroup. This tightly couples the session lifecycle to the context scope, making it difficult to solve #922 ("Attempted to exit cancel scope") under the current design
My previous PR proposes a ClientConnectionManager (#1133) that:
Example:
I'd appreciate any guidance on whether rewriting or replacing ClientSessionGroup would be acceptable, or if there's an alternative approach you'd suggest to address these session lifecycle limitations.