-
Notifications
You must be signed in to change notification settings - Fork 78
Attempt at fixing https://github.com/dart-lang/tools/issues/2202. #2225
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
base: main
Are you sure you want to change the base?
Conversation
I experienced an issue when using a MCP server (using `dart_mcp` which uses this package). Worked well on VM, but when I switched to Web, MCP initialization never returned. As it turns out, the target MCP server does not support CORS (eg. https://api.githubcopilot.com/mcp/) and it seems the error never flows back to the code that initializes the MCP server, so the corresponding future never completes. I've added a test "can send a message and receive an error" that mimics the behavior I observed: the test times out without this fix. The fix consists in forwarding the error to both the client and the server.
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.
Code Review
This pull request effectively addresses an issue where pending requests on a Peer would hang indefinitely if the underlying communication channel produced an error. The fix correctly propagates the channel error to both the client and server components of the Peer, ensuring that pending client requests are properly terminated. The introduction of a new test case successfully validates this fix by simulating a channel error and asserting the expected failure of a pending request. Additionally, enabling web platform testing is a valuable improvement. The code changes, including some nice formatting improvements, are clean, well-tested, and follow Dart best practices.
Package publishing
Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation. |
PR HealthLicense Headers ✔️
All source files should start with a license header. Unrelated files missing license headers
This check can be disabled by tagging the PR with API leaks ✔️The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.
This check can be disabled by tagging the PR with Breaking changes ✔️
This check can be disabled by tagging the PR with Coverage ✔️
This check for test coverage is informational (issues shown here will not fail the PR). This check can be disabled by tagging the PR with Changelog Entry ✔️
Changes to files need to be accounted for in their respective changelogs. This check can be disabled by tagging the PR with |
natebosch
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.
I need to dig a bit more, but as long as this doesn't cause any internal tests to fail I think we can probably land this.
| @@ -0,0 +1,7 @@ | |||
| platforms: | |||
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.
As an FYI the platforms that run on CI are controlled by the .github/workflows/ config, where we were already running web tests.
tools/.github/workflows/json_rpc_2.yaml
Line 71 in 37f8242
| run: dart test --platform chrome --compiler dart2wasm,dart2js |
I think it's fine to check in this file too so that dart test locally is more comprehensive.
| } | ||
| }, onError: (Object error, StackTrace stackTrace) { | ||
| _serverIncomingForwarder.addError(error, stackTrace); | ||
| _clientIncomingForwarder.addError(error, stackTrace); |
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.
Typing out some thoughts as I'm thinking through this change... I want to see if we can find the original intent for this design, it's plausible that this error is intended only to flow to the onUnhandledError handler which is explicitly only set up on the "Server"?
tools/pkgs/json_rpc_2/lib/src/peer.dart
Line 102 in 37f8242
| onUnhandledError: onUnhandledError, |
It doesn't flow there though, so that might be a red herring...
According to blame, I'm the one who landed it this way.
dart-archive/json_rpc_2#65
I have no memory of that change. From the description:
Forward errors to the _server so that it can forward them through
done without an extra Completer to manage.
Looks like there we were focused on the error flowing through done, and we may have missed the cases where an error needs to flow through sendRequest return values.
Hello,
I experienced an issue when using a MCP server (using
dart_mcpwhich uses this package). Worked well on VM, but when I switched to Web, MCP initialization never returned. As it turns out, the target MCP server does not support CORS (eg. https://api.githubcopilot.com/mcp/) and it seems the error never flows back to the code that initializes the MCP server, so the corresponding future never completes. This is tracked in issue #2202.I've added a test "can send a message and receive an error" that mimics the behavior I observed: the test times out without this fix. The fix consists in forwarding the error to both the client and the server. As it turns out, the
Peernever called_clientIncomingForwarder.addError()which seems odd?