the context.RequestAborted not reliable in HandleSseRequestAsync
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start at HandleSseRequestAsync and trace how its linked cancellation token is used by RunSessionAsync. Reproduce the disconnect with MCP Inspector by clicking Connect and quickly pressing Ctrl+F4, then observe whether the request cancellation path runs. Done means an abnormal disconnect cancels the session so RunSessionAsync does not wait indefinitely.
Written by the indexing model from the issue text.
Description
Describe the bug
the Request object will disposed when the connection was not normal disconnected, and the context.RequestAborted has two situations.
1.the context RequestAboated will disposed ,but will not raise registe event notify it was cancelled;because it just disposed.
2.the request will disposed, but the ReuqestAborted not changed,it stay not cancelled state.
the HandleSseRequestAsync method use RequestAborted to created a token source, when the request was disposed this token source will always be not cancelled, because it will not raise Registe event or RequestAborted will always not be cancelled, then the await RunSessionAsync will forever wait for next request.
using CancellationTokenSource sseCts = CancellationTokenSource.CreateLinkedTokenSource(context.RequestAborted, <hostApplicationLifetime>P.ApplicationStopping);
To Reproduce
Steps to reproduce the behavior:
just use mcp inspector ,click the "connect" button ,then quickly use ctrl+F4 to close the webpage,
or use RunSessionHandler to debug then wait it timeout.
Expected behavior
the cancellationToken must to become canceled, even the request was not normal disconnected.
Logs
Additional context
i have not better idea for this, maybe can use context.Reponse.OnCompleted(()=>sseCts.Cancel()) to fix the problem.
- Dominant language
- C#
- Stars
- 4.5k
- Forks
- 814
- Avg merge
- 9d 19h
- Merged PRs (30d)
- 4
Contributor guide
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.
More from modelcontextprotocol/csharp-sdk
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
modelcontextprotocol/csharp-sdk#1867 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
modelcontextprotocol/csharp-sdk#1840 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
modelcontextprotocol/csharp-sdk#1836 ·
-
enhancement needs confirmation
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
modelcontextprotocol/csharp-sdk#678 · 1 comment ·
-
enhancement needs confirmation P3 ready for work
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
modelcontextprotocol/csharp-sdk#515 · 6 comments · 3 reactions ·
All issues in modelcontextprotocol/csharp-sdk
Similar issues
-
core dependencies
Difficulty 1/5 Under an hour Newbie friendliness 80/100
-
bug frontend good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
NavigationViewItemAutomationPeer implements IInvokeProvider but never advertises the Invoke pattern Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
unoplatform/uno#24629 ·
-
agentic-workflows Needs: Triage :mag: State: In-PR
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Down / Waiting for removal
Difficulty 2/5 1-3 hours Newbie friendliness 70/100