An input-validation failure reaches the client as "Unexpected error.", with no indication that the caller sent something invalid or what it was.
{ creativeWorks(perPage: 150) { items { id } } }{ "errors": [ { "message": "Unexpected error.", "path": ["creativeWorks"] } ] }The server knows exactly what happened, and logs it:
ERR Error: perPage must be between 0 and 100; got 150.
at argsToQuery (@lde/search-api-graphql/dist/build-schema.js:457:15)
at resolve (@lde/search-api-graphql/dist/build-schema.js:374:31)
The limit itself is fine. The problem is that a caller-fixable error is presented as a server fault, so the consumer has no path to the fix without shell access to the API container. We only found it because we could read the container's log; a presentation-layer developer building against a hosted endpoint cannot.
It is also silent about where the boundary is: perPage: 100 works and 101 does not, and nothing in the SDL says so — the argument is typed Int with a default of 20, so the playground's own documentation gives no hint either.
Suggested fix
Throw a GraphQLError for argument validation so the message survives to the client, and mark it as a client error — e.g. extensions: { code: 'BAD_USER_INPUT' } — leaving "Unexpected error." for genuinely unexpected faults. Worth applying to the other validated arguments too, not just perPage.
Stating the bound in the argument's SDL description would prevent most encounters with it, and pairs with #722 (field descriptions in the generated SDL).
An input-validation failure reaches the client as
"Unexpected error.", with no indication that the caller sent something invalid or what it was.{ creativeWorks(perPage: 150) { items { id } } }{ "errors": [ { "message": "Unexpected error.", "path": ["creativeWorks"] } ] }The server knows exactly what happened, and logs it:
The limit itself is fine. The problem is that a caller-fixable error is presented as a server fault, so the consumer has no path to the fix without shell access to the API container. We only found it because we could read the container's log; a presentation-layer developer building against a hosted endpoint cannot.
It is also silent about where the boundary is:
perPage: 100works and101does not, and nothing in the SDL says so — the argument is typedIntwith a default of 20, so the playground's own documentation gives no hint either.Suggested fix
Throw a
GraphQLErrorfor argument validation so the message survives to the client, and mark it as a client error — e.g.extensions: { code: 'BAD_USER_INPUT' }— leaving"Unexpected error."for genuinely unexpected faults. Worth applying to the other validated arguments too, not justperPage.Stating the bound in the argument's SDL description would prevent most encounters with it, and pairs with #722 (field descriptions in the generated SDL).