Repository navigation
Improve handling non-compliant Notification responses #586
Description
Bug description
Line 505 of io.modelcontextprotocol.client.transport.HttpClientStreamableHttpTransport. If the result of responseEvent conversion is as follows: AggregateResponseEvent[responseInfo=jdk.internal.net.http.ResponseInfoImpl@67d15067, data=], the obtained data is an empty string. The Utils.hasText method does not recognize empty strings, resulting in an error:
io.modelcontextprotocol.spec.McpTransportException: Error deserializing JSON-RPC message: AggregateResponseEvent[responseInfo=jdk.internal.net.http.ResponseInfoImpl@5e431139, data=]
at io.modelcontextprotocol.client.transport.HttpClientStreamableHttpTransport.lambda$sendMessage$27(HttpClientStreamableHttpTransport.java:515) ~[mcp-core-0.13.1.jar:0.13.1]
at reactor.core.publisher.FluxFlatMap$FlatMapMain.onNext(FluxFlatMap.java:388) ~[reactor-core-3.7.9.jar:3.7.9]
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyInner.onNext(MonoFlatMapMany.java:251) ~[reactor-core-3.7.9.jar:3.7.9]
at reactor.core.publisher.FluxCreate$BufferAsyncSink.drain(FluxCreate.java:880) ~[reactor-core-3.7.9.jar:3.7.9]
at reactor.core.publisher.FluxCreate$BufferAsyncSink.next(FluxCreate.java:805) ~[reactor-core-3.7.9.jar:3.7.9]
at reactor.core.publisher.FluxCreate$SerializedFluxSink.next(FluxCreate.java:163) ~[reactor-core-3.7.9.jar:3.7.9]
at io.modelcontextprotocol.client.transport.ResponseSubscribers$AggregateSubscriber.hookOnComplete(ResponseSubscribers.java:263) ~[mcp-core-0.13.1.jar:0.13.1]
at reactor.core.publisher.BaseSubscriber.onComplete(BaseSubscriber.java:197) ~[reactor-core-3.7.9.jar:3.7.9]
Environment
Mcp Client: SpringBoot 3.5.5 SpringAI 1.1.0-M2
Mcp Java SDK: 0.13.1
Mcp Server: Python FastMCP
Expected behavior
Hopefully, the Utils.hasText() method can be used to recognize empty strings and return Mono.empty() to avoid errors.
Activity
tzolov commentedon Oct 1, 2025
@hbsjz-swl I'm not sure that this is the real issue because we have tests for the Utils.hasText() to validate correct behavior for empty strings.
Can you try to reproduce this issue with a test please?
hbsjz-swl commentedon Oct 1, 2025
Hi @tzolov ,
My apologies for the confusion in my initial report. Thank you for your patience. I've pinpointed the exact issue, and it's a logic bug, not a problem with Utils.hasText().
The problem is located in HttpClientStreamableHttpTransport.java at line 506:
code
This code correctly handles non-compliant responses for a Notification only if the response has text.
However, in my case, the server sends back an empty string "" as the response. For an empty string, Utils.hasText(data) returns false, causing the entire if condition to fail. The code then proceeds to the next line, passing the empty string to the JSON parser, which results in a JsonParseException.
According to the JSON-RPC specification, a Notification should not receive a response at all. Therefore, any response, including an empty one, should be treated as non-compliant and handled gracefully.
The fix would be to remove the && Utils.hasText(data) check, so that any response to a Notification is caught.
Suggested Fix:
code
// Before
// After
or
This change would ensure that both non-empty and empty responses to a Notification are correctly handled by returning Mono.empty(), preventing the crash.
Could you please take a look at this specific logic? Thanks!
[-]The hasText method in the io.modelcontextprotocol.util.Utils tool cannot recognize empty strings[/-][+]Improve handling non-compliant Notification responses [/+]tzolov commentedon Oct 1, 2025
@hbsjz-swl I've updated the title to better reflect the issue you are describing.
Also I would call it a bug as this is a non-compliant Notification responses that the server shouldn't have sent.
Anyway I believe we can improve the condition to tolerate such server discrepancy.
fix: Handle non-compliant notification responses
fix: Handle non-compliant notification responses (modelcontextprotoco…
hbsjz-swl commentedon Oct 2, 2025
@tzolov,
Thank you for your quick follow-up and fix! Your description is correct. I've seen the relevant commit and PR (#589). Thank you for taking the suggestion and improving the SDK to better handle these noncompliant server responses. I look forward to the new version release!
link #115926 Upgrade MCP SDK fork to upstream v0.18.2 for streamable …