test/json-rpc.test.ts (1)

468-658: LGTM — HTTP error code mapping tests are comprehensive.

All major HTTP-to-JSON-RPC mappings are verified. Consider adding tests for 408 (timeout) and 422 (unprocessable entity) if those paths are expected to be exercised by consumers.

src/utils/json-rpc.ts (1)

54-57: JsonRpcMethod receives the full JsonRpcRequest but the docstring says "parameters".

The type signature passes data: JsonRpcRequest<I> (the full request object including jsonrpc, method, id, and params), but the JSDoc on Line 52 says "It receives the parameters from the request." This is accurate for how handlers destructure { params } in practice, but the first argument name data is the entire request object, not just params.

Consider renaming the parameter from data to request (or req) for clarity, since that's what it actually is.

src/utils/json-rpc.ts (1)

389-395: method is typed as unknown — may cause TypeScript errors on strict configs.

req.method resolves to unknown (from Record<string, unknown>), but it's used as a string index into methodMap (line 395) and assigned to JsonRpcRequest.method (line 404). By this point, line 363 has already validated typeof req.method === "string", so the value is safe at runtime, but TypeScript doesn't narrow across the conditional into a separate variable assignment.

Consider adding a cast: const method = req.method as string;

Proposed fix

-  const method = req.method;
+  const method = req.method as string;

test/json-rpc-ws.test.ts (1)

329-350: Inner sendMessage shadows the outer helper — acceptable but worth noting.

The sendMessage in the "batch requests" describe block shadows the one in "message processing". This is fine since they have different method registrations, but if more describe blocks are added, consider extracting a shared configurable helper to reduce duplication.