Invalid description results in unhelpful error message about graphql-erlang HOT 4 CLOSED

Yes, I agree we should be doing something about this. It should be fairly easy to produce a better error message by detecting this explicitly.

from graphql-erlang.

Rough debugging plan:

• Figure out which part of the code the problem occurs in: parser? The canonicalizer itself?
• Handle this gracefully, either by ignoring the annotation, or by failing whenever there are an excess of unknown annotations.

The latter is up for discussion: both semantics are pretty nice: ignoring means you can extend it with stuff in advance. But then again, it also means you don't get an error report, and then you might be confused later on, when the expected behavior isn't there (why is my descriptions not showing up in my API introspection?)

from graphql-erlang.

Better fix for this one: In #161 descriptions are optional (block-) strings on types. So we have somethng like

"Geolocated coordinates"
type Geo {
    "The latitude of the geolocation"
    latitude: Float!
    "The longitude of the geolocation"
    longitude: Float!
}

Which completely solves this problem going forward. Also annotations such as +description will go away since we can just add them as directives to the server. Instead of e.g., +private you can write:

"The Foo object"
type Foo {
    "The private geo position of the Foo object"
    geo: Geo! @private
}

This naturally reuses the directive notion and internally it also makes a lot of sense since annotations and directives share a lot of the same code path, but they are really the same kind of thing.

from graphql-erlang.

The initial (concrete) fix for this has been merged and documentation are now docstrings as per the Jun2018 specification.

As for directives, we plan to support them as per the Jun2018 spec as well. You would write something like the following to implement the old behavior:

directive @ description (text: String) on
  | SCHEMA
  | SCALAR
  | OBJECT
  | FIELD_DEFINITION
  | ARGUMENT_DEFINITION
  | INTERFACE
  | UNION
  | ENUM
  | ENUM_VALUE
  | INPUT_OBJECT
  | INPUT_FIELD_DEFINITION

Which is then entered into the type checker. This will have the type checker detect an error if you use capitalized Text in lieu of text. GraphQL is case sensitive in general, so this follows the basic rules of the game.

NOTE: The example is somewhat degenerate insofar it implements a feature which has been added to the specification. But it shows how a programmer is able to extend the schema with their own ruleset.

from graphql-erlang.