-
Notifications
You must be signed in to change notification settings - Fork 181
#107 Monitor STDERR and refactor StdioClientTransport to use flows
#442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
cb03c52 to
b486d61
Compare
StdioClientTransport to use flowsStdioClientTransport to use flows
3622a8f to
f79acd4
Compare
…ndling, and support for optional error stream. Update dependencies in `libs.versions.toml`.
7cddb91 to
da60e7c
Compare
|
||||||||||||||||||
Replaced a boolean ` processStdError ` callback with `classifyStderr` that returns a `StderrSeverity` enum (FATAL, WARNING, INFO, DEBUG, IGNORE). This allows fine-grained control over stderr message handling: FATAL terminates the transport, while other levels log at appropriate levels or discard messages. Updated KDoc with comprehensive documentation and usage examples.
Enhance `StdioClientTransportTest` with clean shutdown validation, error handling, and added assertions. Extend timeout for stability.
…p test suites, and avoid stack trace truncation.
d4e1ba3 to
16da227
Compare
…ifyStderr` to DEBUG
e5l
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, please check minor comments
| transport.onError { errorCalled = true } | ||
|
|
||
| transport.start() | ||
| delay(100.milliseconds) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
runTest is using virtual time, please make sure the delay is used to skip virtual time and not real
| } catch (e: McpException) { | ||
| logger.debug(e) { "Error while sending message: ${e.message}" } | ||
| throw e | ||
| } catch (e: Exception) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also handle CancellationException (and add a test);
Exception -> Throwable
| handleJSONRPCMessage(event.message) | ||
| } | ||
|
|
||
| is Event.StderrEvent -> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
consider extracting error handling to a separate method (for readability)
# Better exception handling in StdioClientTransport Refactor `McpException` for improved handling with convenience constructors and enhanced exception wrapping logic in `StdioClientTransport`. Update tests to use `kotest` matchers and add JUnit parameterized tests for exception handling. ## Motivation and Context #442 follow up ## How Has This Been Tested? <!-- Have you tested this in a real application? Which scenarios were tested? --> ## Breaking Changes <!-- Will users need to update their code or configurations? --> ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply. --> - [ ] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [ ] My code follows the repository's style guidelines - [ ] New and existing tests pass locally - [ ] I have added appropriate error handling - [ ] I have added or updated documentation as needed ## Additional context <!-- Add any other context, implementation notes, or design decisions -->
Refactor
StdioClientTransportto monitor STDERRStdioClientTransportclass has been enhanced to monitor the standard error (stderr) stream, enabling the detection of fatal errors that should terminate the connection.using coroutine flows and channels
StderrSeverityenum (FATAL,WARNING,INFO,DEBUG,IGNORE)classification for flexible error handling
and in-memory streams
Motivation and Context
Fix for #107
How Has This Been Tested?
Regression tests, integration test added
Breaking Changes
Types of changes
Checklist
Additional context