Repository navigation
Conversation
#318) checkRequestId only refused unsafe numeric ids, so requests with an id of null, a boolean, an object or an array were processed and the id echoed back. Any message that carries an `id` key whose value is not a string or a safe integer is now answered with -32600 Invalid Request and id: null, on HTTP and stdio alike. Messages without an `id` key are still handled as notifications, and a client error response with a null id (JSON-RPC 2.0 section 5) is still accepted. Fixes #318 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LmhsFjk8W96X2PvmShmDm9
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
checkRequestIdonly refused numeric ids outside the safe integer range. Any other non-conforming id (null,true,{"a":1},[1]) was processed and echoed back, e.g.{"id":null,"result":{}}.The check now refuses every message that carries an
idkey whose value is not a string or a safe integer. These get-32600 Invalid Requestwithid: null. The same function runs on the HTTP POST route and on the stdio transport before inject, so both behave the same way.Behavior that stays the same:
idkey is still a notification (HTTP 202, no reply on stdio).id: nullis still accepted, since JSON-RPC 2.0 section 5 allows it when the request id couldn't be determined.On the stdio
object:[object Object]in-flight key mentioned in the issue: object ids are now rejected before they reach request handling, so they can no longer end up sharing a slot.Tests
test/index.test.ts: null, true, false, object, array and 1.5 ids get 400 / -32600 / id null. A notification without an id still gets 202. A client error response with a null id is accepted. String and integer ids are echoed.test/stdio.test.ts: the same invalid ids get -32600 / id null. A notification gets no reply. String and integer ids are echoed.npm run lint,npm run typecheckandnpm run testall pass, exceptdistributed-lock.test.ts > should extend Redis lock TTL. That test is timing-based and fails intermittently on its own (1 of 3 isolated reruns), and this change doesn't touch it.Fixes #318
🤖 Generated with Claude Code
https://claude.ai/code/session_01LmhsFjk8W96X2PvmShmDm9