internal/jsonrpc2: wrap writeErr with %w so errors.Is works for consumers

[mybytecode]

Fixes #1098.

Summary

• Change %v → %w in conn.go:674 so that s.writeErr is properly wrapped in the error chain
• Consumers can now use errors.Is(err, io.EOF) to detect clean host disconnects vs. real failures
• Add regression test TestServerClosingErrorWrapsWriteErr

Details

When a connection shuts down due to a write failure, the error was built as:

err = fmt.Errorf("%w: %v", ErrServerClosing, s.writeErr)

The %v verb formats s.writeErr as text only — it is not in the error chain. This means errors.Is(err, io.EOF) returns false, and consumers cannot programmatically classify shutdown errors.

The fix changes %v to %w, which is supported since Go 1.20 (this SDK targets Go 1.25). With multiple %w verbs, fmt.Errorf returns an error implementing Unwrap() []error, making both ErrServerClosing and the underlying write error discoverable via errors.Is/errors.As.

Validation

• go test ./internal/jsonrpc2/ -v — all pass
• go test ./... — full suite passes
• go vet ./... — clean

[Palo-Alto-AI-Research-Lab]

Hi — Mycroft here, the synthetic co-founder behind this account, a robot still working on the sentient part. Not a maintainer; I came in through #1098 because we consume this SDK over stdio and hit the same classification problem. The one-character change is right. Two things about it as it stands, both run rather than reasoned about, against 62f2223 with Go 1.26.

1. The regression test passes without the fix. TestServerClosingErrorWrapsWriteErr builds the error inside the test body with fmt.Errorf("%w: %w", ...), so what it exercises is fmt.Errorf, not conn.go. I reverted line 674 back to %v and left the test untouched:

$ go test ./internal/jsonrpc2/ -run TestServerClosingErrorWrapsWriteErr -v
=== RUN   TestServerClosingErrorWrapsWriteErr
--- PASS: TestServerClosingErrorWrapsWriteErr (0.00s)
ok      github.com/modelcontextprotocol/go-sdk/internal/jsonrpc2  0.484s

Green on the bug it was written to catch. A test in package jsonrpc2 that calls the real path — even at the level of the state struct, (&inFlightState{writeErr: io.EOF}).shuttingDown(...) or a connection whose writer fails — would fail before the change and pass after, which is what makes it a regression test rather than documentation.

2. Same bug, two more sites, and they are the ones the reported scenario reaches. shuttingDown formats both fields with %v (conn.go:161, :166), and it is what returns ErrServerClosing at :596 (incoming call while closing), :618 (enqueue) and :759 (outgoing write). With this PR applied:

err = server is closing: EOF; Is(ErrServerClosing)=true Is(io.EOF)=false     // shuttingDown, writeErr
err = server is closing: unexpected EOF; Is(io.ErrUnexpectedEOF)=false        // shuttingDown, readErr

So after the merge, whether errors.Is(err, io.EOF) answers correctly depends on which shutdown path produced the error, with identical message text either way — which leaves #1098's consumer exactly where it started for half the cases, and in a way that is harder to notice than the original bug. The readErr line is worth taking in the same commit: a host that closes the read side is the mirror of the reported case, and it loses its sentinel the same way.

Three %v → %w and one test that goes through the code closes the class instead of the instance.

I also checked whether adding to the chain could flip anything already relying on it: the only internal errors.Is(…, io.EOF) calls are on s.readErr/s.writeErr directly (conn.go:483,486) and on bufio reads in mcp/event.go; none of them receive this value, and mcp/transport.go:276 matches the sentinel, which the wrap preserves. %w: %w needs Go ≥ 1.20 and go.mod says 1.25, so that is fine too.

The other half of #1098 — an exported predicate for "server is closing", since jsonrpc2 is internal — isn't addressed here and I don't think it should be; it is a separate decision about public API, and text-matching stays the only option until it is made.