Commit Graph

7 Commits

Author SHA1 Message Date
Auke Booij
8e600362e7 Improve error message phrasing in safeSelectionSet
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6053
GitOrigin-RevId: c2595f396845e9ca809b93566b38239d80a244b8
2022-09-27 06:08:25 +00:00
Auke Booij
6d84d1b78f Improve error reporting by tracking more Metadata origins
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5740
GitOrigin-RevId: 555de02a370b1dfa9cf5e903bb5c3f4b4c3e8465
2022-09-06 14:19:48 +00:00
Samir Talwar
1e1a36a192 server/tests-py: Use environment variables for services in queries.
I'm trying to shore up the Python integration tests to make them more reliable. In doing so, I noticed this.

---

Rather than hard-coding hostnames and ports, we can (and already do) inject these into the HGE process using environment variables.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5255
GitOrigin-RevId: 6bb593999ece42cedef6619f31f9d9b2e39f30ef
2022-08-03 20:05:46 +00:00
Samir Talwar
33b19c327c Replace Data.Text.Extended with ErrorMessage in a few more places.
Mostly in the schema parsers code, to reduce its exposure to the rest of
the codebase.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5088
GitOrigin-RevId: 752fcc10b4748b601e2e5313db326fe7f84febb4
2022-07-25 10:42:03 +00:00
Auke Booij
8ccf7724ce server: Metadata origin for definitions (type parameter version v2)
The code that builds the GraphQL schema, and `buildGQLContext` in particular, is partial: not every value of `(ServerConfigCtx, GraphQLQueryType, SourceCache, HashMap RemoteSchemaName (RemoteSchemaCtx, MetadataObject), ActionCache, AnnotatedCustomTypes)` results in a valid GraphQL schema. When it fails, we want to be able to return better error messages than we currently do.

The key thing that is missing is a way to trace back GraphQL type information to their origin from the Hasura metadata. Currently, we have a number of correctness checks of our GraphQL schema. But these correctness checks only have access to pure GraphQL type information, and hence can only report errors in terms of that. Possibly the worst is the "conflicting definitions" error, which, in practice, can only be debugged by Hasura engineers. This is terrible DX for customers.

This PR allows us to print better error messages, by adding a field to the `Definition` type that traces the GraphQL type to its origin in the metadata. So the idea is simple: just add `MetadataObjId`, or `Maybe` that, or some other sum type of that, to `Definition`.

However, we want to avoid having to import a `Hasura.RQL` module from `Hasura.GraphQL.Parser`. So we instead define this additional field of `Definition` through a new type parameter, which is threaded through in `Hasura.GraphQL.Parser`. We then define type synonyms in `Hasura.GraphQL.Schema.Parser` that fill in this type parameter, so that it is not visible for the majority of the codebase.

The idea of associating metadata information to `Definition`s really comes to fruition when combined with hasura/graphql-engine-mono#4517. Their combination would allow us to use the API of fatal errors (just like the current `MonadError QErr`) to report _inconsistencies_ in the metadata. Such inconsistencies are then _automatically_ ignored. So no ad-hoc decisions need to be made on how to cut out inconsistent metadata from the GraphQL schema. This will allow us to report much better errors, as well as improve the likelihood of a successful HGE startup.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4770
Co-authored-by: Samir Talwar <47582+SamirTalwar@users.noreply.github.com>
GitOrigin-RevId: 728402b0cae83ae8e83463a826ceeb609001acae
2022-06-28 15:53:44 +00:00
David Overton
ddad668f07 Fix/custom table name
GitOrigin-RevId: 5004717ac7d9e848ca186a1cdf52e375547034bf
2021-05-18 13:37:27 +00:00
Karthikeyan Chinnakonda
fe0ca00640 add tests 2020-09-01 17:13:42 +05:30