If an integer > int32 then it is parsed as overflown value. Instead, throw a parse error.

It seems that before version 2.0.6 was released, it was possible to make requests with an invalid JSON string as the query.
Specifically, the JSON spec requires that within strings, newlines characters must be escaped, per RFC 4627

All Unicode characters may be placed within the quotation marks except for the characters that must be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F).

But before 2.0.6, it was possible to make requests with payloads that looked like this (note the unescaped newlines)

{"query":"query DataTreppPropertyUSAAddressDataTest{
  trepp_property{
    usa_address__address{
      one_line_address
    }
  }
}","variables":null,"operationName":"DataTreppPropertyUSAAddressDataTest"}

This is no longer possible.
The new, spec-compliant behavior was most likely introduced in this commit, which has a fairly lengthy explanation on the origin of the bug and why and how it was fixed. Edit: or maybe not.

Of course most graphql clients will process query strings and produce an escaped string when converting to JSON, so most users did not notice the change.

Emphasis on most. This issue is to discuss whether we should consider introducing backwards compatibility for the previous behavior.

TODO

• add tasty, tasty-hedgehog, etc. as dependencies
• convert existing tests to the new framework
• use tasty-discover for automated test case discovery
• make sure that test logic works as expected
  • tasty checks in parallel by default, so tests must not assume that they can be run sequentially

Description

We use hspec in the monorepo but I suspect we might benefit from using tasty as the test runner (in addition to hspec) since we’re using tasty-bench for automated benchmarks anyway.

At the very least this repo would be a convenient place to test the idea on a small scale, since the existing hedgehog-based test suite makes it a little inconvenient to add unit tests.

Hi people!

This is great work, we plan on using this parser for our GraphQL integration, would it be possible for it to be released to Hackage?

Thanks! 👏

The Haskell library component currently depends on Hedgehog, even when building only the library. The only reason for this is src/Language/GraphQL/Draft/Generator.hs, which is marked in the exposed-modules of the library.

Presumably, the reason for this is that both the test suite and the benchmark use that file.

Can we avoid this dependency on Hedgehog by making src/Language/GraphQL/Draft/Generator.hs part of the test suite and benchmark directly? It might end up getting compiled twice (once for the tests, once for the benchmarks). In return, it would not get built at all for the library. This would be preferable over pulling in both Hedgehog and Language.GraphQL.Draft.Generator into the library, even though both never get used.

TODO:

• Finish filling out this issue description

@0x777 Can you add to the readme that mentions attributions and history of repo?

Description

Just what it says on the tin:

We should add version bounds (at the very least lower bounds) for any test/benchmark suite dependencies which are not already covered by bounds on library dependencies.

We currently track the Hackage index state in ci.yml and weeder.yml; this should probably be moved out to a proper cabal.project.freeze file corresponding to each of the package sets we need to test against (i.e. one for each of the major versions of GHC that we support).

See pg-client-hs for details.

We don't seem to support the block strings defined in the GraphQL spec:

For example, the following operation containing a block string:

mutation {
  sendEmail(message: """
    Hello,
      World!

    Yours,
      GraphQL.
  """)
}

Is identical to the standard quoted string:

mutation {
  sendEmail(message: "Hello,\n  World!\n\nYours,\n  GraphQL.")
}

Note that the parsing of this is rather nontrivial:

Since block strings represent freeform text often used in indented positions, the string value semantics of a block string excludes uniform indentation and blank initial and trailing lines via BlockStringValue().

Here, BlockStringValue is a highly nontrivial function that basically says we should ignore any indentation that is common to all lines in a block string. Indeed, the above queries are not equivalent to:

mutation {
  sendEmail(message: "    Hello,\n      World!\n\n    Yours,\n      GraphQL.\n  """)
}

I think the easiest solution here is to parse the string including indentation, and attempt to replicate BlockStringValue to remove indentation afterwards. (I say this explicitly because one can also write indentation-aware parsers using parser combinators alone.)

Needed for parsing defaultValue string from introspection (https://facebook.github.io/graphql/June2018/#sec-The-__InputValue-Type).

cf. https://github.com/hasura/graphql-parser-hs/runs/6132651300?check_suite_focus=true for details & seed to reproduce failing hedgehog case.

EDIT: Grabbing the seeds in case GitHub tosses the logs at some point

    This failure can be reproduced by running:
    > recheck (Size 67) (Seed 2550938587970627962 842345040522762081) property [ parse (lazyTextBuilderPrint ast) == ast ]

For the GraphQL AST. This will be required by graphql-engine for various purposes.

Bug surfaced in hasura/graphql-engine#3597

PR: #21

TODO:

• - Fix issue
• - Reference new commit from engine
• - Verify fix manually
• - Add python test to replicate issue
• - Run python test suite
• - Merge PR to parser
• - Reference commit in engine

Parsing a schema fails if the schema includes descriptions. For example:

"""
simple schema
"""
type Query {
  simpleTest: Int!
}

Upon running parseSchemaDoc with this schema, the error is:

Left "type document error > typeDefinition error!: string"

Can we abandon hpack and get back to plain *.cabal? As a benefit it would make it easy to use Cabal's "new-build" projects (cabal.project) with remote repositories like this one. I am not sure if Cabal does not support hpack, but my experience tells me that hpack does not help in a longer term (it's selling points are minute).

Self-explanatory.

No reason to use CircleCI if we're using GitHub Actions for other public projects like https://github.com/hasura/pg-client-hs.