question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Spec Compliance: Strict input coercion for scalars

See original GitHub issue

The GraphQL specification defines strict rules for input coercion, especially of scalar types: http://facebook.github.io/graphql/October2016/#sec-Scalars

However, inputs that are passed in as variables are not validated accordingly, while literals are. parseValue mostly behaves the same as serialize - which allows for some loose coercion.

If i understand the specification correctly, such loose coercion is only allowed for results - outbound information that the server sends to the client. It makes sense in this case, the server should not break the contract it defines in its schema.

Inputs, regardless if they are provided as literals or as variables, are inbound information which come from the client and are sent to the server. In that case, strict validation makes absolute sense - if the client sends bad data, the server should not quietly coerce the value but rather throw an error.

While literals and variables have to be handled differently at first, they both fall into the category of Input Coercion. The spec is really clear on how inputs should be handled, see Section 6.1.2:

If the operation has defined any variables, then the values for those variables need to be coerced using the input coercion rules of variable’s declared type.

What is currently happening is that the result coercion rules, which are different from input coercion rules, are applied to input variables. On the other hand, input literals are treated different than input variables - while according to the specification, they should be handled the same in regards to the coercion.

It seems like there is a fundamental misunderstanding here. If it is on my side, maybe you can clear it up for me? If not, i think resolving this issue to ensure spec compliance requires breaking changes to the implementation.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:1
  • Comments:8 (4 by maintainers)

github_iconTop GitHub Comments

2reactions
ahouzzercommented, Nov 20, 2019

@dchambers LOL. Thanks. I have solved the problem by writing a small converter for input arguments.

2reactions
leebyroncommented, Jun 11, 2018

Some great improves came from this issue, thanks for filing it!

Read more comments on GitHub >

github_iconTop Results From Across the Web

GraphQL scalars and their input and result coercion
In this list, we will go through each default scalar type. We will also discuss rules for result and input coercion and where...
Read more >
4. Coercion - You Don't Know JS: Types & Grammar [Book]
It may not be obvious, but JavaScript coercions always result in one of the scalar primitive (see Chapter 2) values, like string ,...
Read more >
JSON-LD 1.1 - W3C
This document is a detailed specification for a serialization of Linked Data in JSON. The document is primarily intended for the following ...
Read more >
Scalars - Shopify Developers
Scalars ; String. Represents textual data as UTF-8 character sequences. This type is most often used by GraphQL to represent free-form human-readable text....
Read more >
PartiQL Specification
9.1 Coercion of a SELECT subquery into a scalar . ... are compliant with all relevant portions of the Specification (“Compliant ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found