Deserialization errors are indistinguishable from connection loss - how to debug?

[StevenTCramer]

Title: Deserialization errors are indistinguishable from connection loss - no way to debug

Body:

According to the disconnecting documentation, when "a message is received that does not parse to a valid JSON-RPC message", the connection is terminated and all outstanding requests are faulted with ConnectionLostException.

This makes it impossible to debug deserialization issues when using SystemTextJsonFormatter for AOT scenarios.

Reproduction

1. Use SystemTextJsonFormatter with a JSON-RPC server
2. If the response cannot be deserialized (missing type info, wrong format, etc.)
3. Get ConnectionLostException with no information about the actual deserialization error

Current behavior

• Deserialization failure → Connection terminated → ConnectionLostException
• No way to see what actually failed to deserialize
• No stack trace or inner exception with the actual error

Expected behavior

Either:

• Deserialization errors should be reported differently from actual connection loss
• The original deserialization exception should be available as an InnerException
• Some logging/tracing should capture the actual error before treating it as a protocol violation

Impact

This makes it nearly impossible to use SystemTextJsonFormatter with third-party JSON-RPC servers (like Model Context Protocol servers) because when deserialization fails, there's no way to debug what went wrong.

Example

Working with JsonMessageFormatter but failing with SystemTextJsonFormatter:

var formatter = new SystemTextJsonFormatter
{
    JsonSerializerOptions = McpJsonUtilities.DefaultOptions
};
// Fails with ConnectionLostException, no idea why

Is there any way to see the actual deserialization error that causes the connection to be terminated?

[StevenTCramer]

UPDATE - Workaround Found (Core Issue Remains)

After hours of debugging, we found a workaround but the core issue of deserialization errors being indistinguishable from connection loss remains unresolved.

What we discovered:

1. StreamJsonRpc 2.22.11 with SystemTextJsonFormatter causes ConnectionLostException with MCP servers
2. We cloned StreamJsonRpc locally and added debug logging to SystemTextJsonFormatter.Deserialize
3. With our locally compiled version, everything worked perfectly (no code changes, just debug logging added)
4. This led us to try StreamJsonRpc 2.23.32-alpha, which also works

What we DIDN'T discover:

• What the actual bug in 2.22.11 was
• Why the connection was being closed
• What the actual "deserialization error" was (if there even was one)

The core problem remains:

When StreamJsonRpc encounters what it considers an invalid message, it still:

• Terminates the connection immediately
• Throws ConnectionLostException with no inner exception
• Provides no way to see what actually went wrong
• Makes debugging nearly impossible

Workaround:

If you're getting ConnectionLostException with SystemTextJsonFormatter, try upgrading to StreamJsonRpc 2.23.32-alpha or newer. There's apparently a fix for something in there, though we never figured out what.

But this doesn't solve the fundamental issue that deserialization problems are completely opaque to developers.

[AArnott]

Thanks for sharing.

Have you tried the troubleshooting doc? In particular, adding a TraceSource with a listener to both sides? We tend to log quite a bit if you crank up verbosity, so I'd be surprised if what you need isn't there.

[StevenTCramer]

Awesome, no i had not tried it. But will thanks. Another case of "Read the docs" . Sorry.