-
Notifications
You must be signed in to change notification settings - Fork 156
Description
Describe the bug
When the coroutine running a handler is cancelled, it throws a kotlinx.coroutines.JobCancellationException
. The MCP SDK is picking this up and logging this as an error, instead of gracefully ignoring it. To exacerbate the issue, in the IntelliJ IDE, logs with error
severity are presented to the user in a notification bubble. This should not be happening for something as mundane as a coroutine being cancelled.
To Reproduce
Steps to reproduce the behavior:
- Create a MCP server with a handler and have that handler throw a
java.util.concurrent.CancellationException
or any subclass of.
Expected behavior
The coroutine should gracefully shut down without an error being logged.
Logs
Error handling request: tools/list (id: NumberId(value=1))
kotlinx.coroutines.JobCancellationException: Job was cancelled; job=SupervisorJobImpl{Cancelled}@695a8e2e
And yes, that is the extent of the stack trace, as cancellation exceptions suppress the stack trace.
Additional context
In one specific example I'm looking at, the issue is happening here. However the code has this issue all over the place.
While this issue is about CancellationException
being logged, I might argue that a different approach for logging is needed. As mentioned, IntelliJ IDEs present any logs with error level to the user in a notification bubble. Other apps may treat logs differently. Thus the application using the SDK needs to be able to control them. I might argue that the SDK shouldn't emit logs (at least errors) at all, and that it should be raising exceptions which the application can decide what to do with. Another option might be to allow overriding the logger, without having to resort to all sorts of shenanigans to hijack the SDK's call to KotlinLogging.logger
, or hook into slf4j, etc.