GeezerVison

For reviewers — summary to ease review:

Bug: when an incoming message is valid JSON but fails JSON-RPC envelope validation (e.g. "jsonrpc":"1.0", missing jsonrpc, non-string method), the error response couldn't be correlated to the request — stdio never answered at all; Streamable HTTP replied with a null id. (Issue #2848 has 3 repro cases.)

Fix: a shared extract_raw_request_id() helper pulls the id best-effort from the raw payload (only spec-valid id types — str / non-bool int), preserved in the error response on both transports, with null-id fallback per JSON-RPC 2.0 when no valid id exists.

Two deliberate calls worth a look:

1. stdio now also answers unparseable lines with -32700 Parse error (matching HTTP's existing behavior) instead of silently dropping.
2. Envelope-invalid messages now report -32600 Invalid Request instead of -32602 Invalid params (the repro cases are envelope violations, not param errors) — aligns with the codes touched in the recently-merged Fix unknown-method error code and add a protocol version registry #2836.

Both repro cases covered on both transports + null-id fallbacks. Full suite (1785), ruff, pyright all pass. If you'd rather land just the id-correlation core and split the stdio parse-error / error-code changes, I'm glad to narrow it.

Rebased onto 57394b0 — the branch had drifted into conflicts. Same six files, no substantive change to the diff.

On the needs confirmation label: all three envelope-invalid inputs from #2848 still behave as reported on current main. Running this PR's tests against unpatched 57394b0:

• stdio — no JSON-RPC error response is written at all: assert [] == [3, 4, 8, None], the ids that should have come back.
• streamable HTTP — 400 with id: null and -32602 for all three, e.g. {"jsonrpc":"2.0","id":null,"error":{"code":-32602,"message":"Validation error: 6 validation errors for union[...]"}}.

Same numbers @Parker-Fawcett got on the issue.

One thing worth deciding before this lands. This PR covers stdio and the 2025-era streamable HTTP entry; the 2026-07-28 entry still answers an envelope-invalid body with _INVALID_BODY, i.e. id: null. I left it alone deliberately: that shape is currently asserted as SDK-defined in test_handle_modern_request_rejects_a_body_that_is_neither_request_nor_notification, and correlating there flips two of its params — posted-response and posted-error both carry a valid id, and echoing an id back on a body that isn't a request looks like the wrong answer. Restricting correlation to request-shaped bodies is a semantics call, not a bug fix, so I'd rather you make it: happy to extend this PR, or leave it as a follow-up.

Local on f52691d: 5748 passed / 9 skipped / 1 xfailed, coverage report 100.00%, ruff check and ruff format --check clean, pyright 0 errors.

Thanks for the PR, and sorry it sat here without a proper review.

We're closing most of the open PR backlog. v2 is out and changed a lot of the SDK, so many older PRs no longer apply as written, and we're a small team that realistically doesn't have the capacity to work through the rest.

If this still matters to you on v2, the most useful thing you can do is open an issue (or comment on the existing one) with your use case and a repro. Hearing why it matters to you is what we use to decide what to prioritise.

_{AI Disclaimer}