You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 2, 2024. It is now read-only.
This way, ... on Error is a catch-all for errors. If we add a new error in the future, backend will return it and even an outdated frontend should be able to handle it as a generic Error until we implement a specific logic for it. For instance, InternalServerError should be treated as Error as the query does not know it in advance, but the API returned it.
When receiving a __typename: InternalServerError, no case will be matched and it will return a generic Courier$Query$CourierResult which is not convertible to Courier$Query$CourierResult$Error and does not have the message property. This way, we may lose valuable information
What I propose is to add some kind of logic for detecting types which extend an interface, and queries which use interfaces.
I suppose I can manually create a custom parser for this.
Our schema looks like this:
This schema was inspired by this blog post: https://blog.logrocket.com/handling-graphql-errors-like-a-champ-with-unions-and-interfaces/
When consuming this schema, we use the following query:
This way,
... on Error
is a catch-all for errors. If we add a new error in the future, backend will return it and even an outdated frontend should be able to handle it as a genericError
until we implement a specific logic for it. For instance,InternalServerError
should be treated asError
as the query does not know it in advance, but the API returned it.What Artemis currently does is the following:
When receiving a
__typename: InternalServerError
, no case will be matched and it will return a genericCourier$Query$CourierResult
which is not convertible toCourier$Query$CourierResult$Error
and does not have themessage
property. This way, we may lose valuable informationWhat I propose is to add some kind of logic for detecting types which extend an interface, and queries which use interfaces.
I suppose I can manually create a custom parser for this.
Specs
Artemis version: 6.15.1-beta.1
build.yaml:
Artemis output:
GraphQL schema:
GraphQL query:
The text was updated successfully, but these errors were encountered: