feat(package/gqty): Use GraphQLError over plain objects in defaultResponseHandler

[vicary]

No description provided.

[github-actions]

🚀 Snapshot Release (canary)

The latest changes of this PR are available as canary on npm (based on the declared changesets):

Package	Version	Info
@gqty/cli	4.2.2-canary-20250131112755.43462e94e3bde969ca87ef505b89c46a22cec873	npm ↗︎ unpkg ↗︎
gqty	3.3.0-canary-20250131112755.43462e94e3bde969ca87ef505b89c46a22cec873	npm ↗︎ unpkg ↗︎
@gqty/logger	4.0.0-canary-20250131112755.43462e94e3bde969ca87ef505b89c46a22cec873	npm ↗︎ unpkg ↗︎
@gqty/react	4.0.0-canary-20250131112755.43462e94e3bde969ca87ef505b89c46a22cec873	npm ↗︎ unpkg ↗︎
@gqty/solid	1.0.0-canary-20250131112755.43462e94e3bde969ca87ef505b89c46a22cec873	npm ↗︎ unpkg ↗︎

[kleberbaum]

Does seem to work:

Throws error like expected:

As the object is now a array of new GraphQLError shouldn't be re-throwing it like this also become possible?:

In my tests I wasn't able to get any positive Results for it tho:

[vicary]

@kleberbaum Is it possible that Pylon is using the error trace for location/path look up?

In that case a new Error must be created at the callsite of a resolver, if that works it also begs the question of why new Error at query fetcher also works with Pylon.

[kleberbaum]

@kleberbaum Is it possible that Pylon is using the error trace for location/path look up?

In that case a new Error must be created at the callsite of a resolver, if that works it also begs the question of why new Error at query fetcher also works with Pylon.

Good question tbh idk. Lets ask @schettn.

[kleberbaum]

I kinda think that all fetch errors including "Network Errors" should also be returned as GQtyError, but but with empty GraphQLError Array. Currently they are just any error.

[vicary]

It's simply because the design choice of a generated client, where network errors are throwing at fetch() before response handler have a chance to process it.

We want the query fetcher to stay highly customizable rather than a blackbox client. You may have to catch network errors at fetch() for the moment.

Your idea definitely helps with the design of the upcoming modular/plugin system though.

[schettn]

Does seem to work: Throws error like expected:

As the object is now a array of new GraphQLError shouldn't be re-throwing it like this also become possible?:

In my tests I wasn't able to get any positive Results for it tho:

@vicary @kleberbaum What is the instance of the error.graphqlErrors[0]. It has to be GraphQLError, if not the error won't be returned because of error masking. https://the-guild.dev/graphql/yoga-server/docs/features/error-masking.

So are graphqlErrorsjust plain objects or real errors?

[schettn]

@kleberbaum You may check it with console.log(error.graphqlErrors[0] instanceof GraphQLError)

[kleberbaum]

Yes.

[kleberbaum]

GraphQLError Array

[kleberbaum]

At the moment I am only on the phone but I already have a test environment. Will push it on getcronit fork.

[schettn]

@kleberbaum Double check it with the console log.

If it's true and still not working there could be a version mismatch. (Maybe a different graphql version is installed for gqty and pylon.)

[kleberbaum]

@kleberbaum Double check it with the console log.

If it's true and still not working there could be a version mismatch. (Maybe a different graphql version is installed for gqty and pylon.)

True. The issue was that there was a mismatch between GraphQL versions. Therefore, an instance of GraphQLError is not an instance of GraphQLError and can't be thrown:
"graphql": "^16.10.0" and "graphql": "^16.9.0"

It was solved by forcing "16.9.0" for the pnpm workspace:

Unfortunately, it is always possible that the GraphQL version of a project is not the same as in GQty and then the error will be masked by Apollo.

[vicary]

graphql is only a peer dependency of gqty, package managers should be able to dedupe them.

[vicary]

@kleberbaum Could resolve the version conflict without using explicit overrides? We can merge this one so I can move on to the pylon schema.

[kleberbaum]

@kleberbaum Could resolve the version conflict without using explicit overrides? We can merge this one so I can move on to the pylon schema.

Wasn't able to verify yet if it works in another environment. I was only able to confirm that In the gqty repo pnpm workspace it is not working without the override if the project using GQty is adding a different graphql version in package json.