Technical Issue: Improve Error Context for GraphQL Parsing and Validation Failures
While reviewing the library, I noticed an opportunity to make GraphQL parsing and validation failures easier for downstream users to diagnose.
Problem
When a query or document fails during parsing or validation, consumers generally need enough context to identify the source of the failure and understand where in the GraphQL document it occurred. If that context is not consistently preserved by the error path, callers may have to inspect or reconstruct the original input themselves.
Suggested improvement
Consider standardizing the error information returned from parsing and validation failures so that errors consistently expose:
- A clear distinction between syntax/parsing errors and validation errors.
- The underlying error or validation reason without losing useful context.
- Source location information such as line and column when available.
- The relevant GraphQL operation or document context where practical.
- Tests covering representative malformed queries and validation failures.
This would make the library easier to integrate into tooling such as editors, linters, API gateways, and server-side GraphQL clients, where actionable diagnostics are important.
If the library already has an established error type or diagnostic model, the improvement could build on that existing API rather than introducing a separate error mechanism.
Technical Issue: Improve Error Context for GraphQL Parsing and Validation Failures
While reviewing the library, I noticed an opportunity to make GraphQL parsing and validation failures easier for downstream users to diagnose.
Problem
When a query or document fails during parsing or validation, consumers generally need enough context to identify the source of the failure and understand where in the GraphQL document it occurred. If that context is not consistently preserved by the error path, callers may have to inspect or reconstruct the original input themselves.
Suggested improvement
Consider standardizing the error information returned from parsing and validation failures so that errors consistently expose:
This would make the library easier to integrate into tooling such as editors, linters, API gateways, and server-side GraphQL clients, where actionable diagnostics are important.
If the library already has an established error type or diagnostic model, the improvement could build on that existing API rather than introducing a separate error mechanism.