[pawell67]

Problem

RequestParser::bodyParams() accepts any associative array as a single operation. A JSON object that also carries the key "0", e.g.

{"query":"{ foo }","0":"not an operation"}

decodes to a PHP array with the integer key 0. Arr::isAssoc() still reports it as associative, so the parser returns it as a single operation, but GraphQL\Server\Helper::parseRequestParams() uses isset($bodyParams[0]) to detect a batch and then calls OperationParams::create() with each entry. The string entries make that an uncaught TypeError:

GraphQL\Server\OperationParams::create(): Argument #1 ($params) must be of type array, string given, called in .../webonyx/graphql-php/src/Server/Helper.php on line 127

That surfaces as an HTTP 500 and an unhandled exception in error tracking, instead of the BadRequestGraphQLException (HTTP 400) the parser throws for every other malformed body. We hit this in production from a scanner sending a multipart-upload-shaped payload (operations, map, "0") as application/json.

Fix

Use the same rule as webonyx to tell a batch from a single operation: a body with the key 0 is a batch, and every entry of a batch must be an object. Anything else falls through to the existing BadRequestGraphQLException.

Behaviour for valid bodies is unchanged: a JSON object without the key 0 is still a single operation, a list of objects is still a batch.

Tests

• testObjectWithNumericKeyIsNotABatch reproduces the TypeError on master and passes with the fix.
• testBatchWithNonObjectEntry pins the existing rejection of a list containing a non-object entry.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

A key 0 with a null value still bypasses the intended rejection path.

1 open finding

• Reject null-valued numeric keys with key-existence checking · New

What changed in this PR

Ensures malformed GraphQL JSON bodies with numeric key 0 return HTTP 400 instead of causing an uncaught TypeError.

Changes:

• Aligns request validation with webonyx batch detection.
• Adds regression tests for malformed batch-like bodies.
• Documents the fix.

File	Description
src/​RequestParser.php	Validates bodies detected as batches.
tests/​Unit/​RequestParserTest.php	Adds malformed-body regression tests.
CHANGELOG.md	Records the corrected behavior.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[spawnia]

🤖 Thanks @pawell67, I pushed three commits on top of yours.

• Keep rejecting batches that start with null: [null] is rejected again, as on master.
• Shorten comments.
• Reject malformed multipart operations: multipart operations such as {"query":"…","0":"x"} hit the same TypeError, so they now go through the same check.

[Copilot]

🟡 Changes recommended

The implementation is sound, but its inline and changelog documentation inaccurately overstate how null and valid object entries at key 0 are handled.

2 open findings

• Narrow release note to malformed batch entry rejection · New
• Clarify non-null index 0 requirement in batch detection comment · New

1 resolved since last review

• Reject null-valued numeric keys with key-existence checking

🧠 Review effort: Balanced