[object Object] is returned from a binding when resolver throws an error

[ghost]

I've noticed that when a query/mutation is executed via a graphql binding an [Object object] error is returned. This behaviour is observed when an error is thrown in resolver as a part of a business logic.

const resolvers = {
  Query: {
    test: async (parent, args, context) => {
      // some random _id that is passed as a query arg 
      const _id = '507f1f77bcf86cd799439011';
      const binding = await context.bindings.organisations.query.organisation({ _id }, '{ _id }', { context: { foo: 'foo' } });
      return 'foo';
    }
  }
};

organisation query throws an Apollo error when organisation is not found by id.

Funny enough the cause is an old version of graphql-tools and the PR for it was already made: #161

When will it be merged?

[Pajk]

Hi, it's still happening with the latest version. There's no way how to find out what went wrong. I tried to inspect the error but there's nothing helpful.

Error: [object Object]
  at new CombinedError (/app/node_modules/graphql-tools/dist/stitching/errors.js:82:28)

// err.originalError.errors[0]
{ Error: [object Object]
    at asErrorInstance (/app/node_modules/graphql/execution/execute.js:489:43)
    at process._tickCallback (internal/process/next_tick.js:68:7)
  message: '[object Object]',
  locations: [],
  path: [ 'testMutation' ]
}

[Pajk]

I found a workaround at ardatan/graphql-tools#480 (comment).

For anyone interested:

import { onError } from 'apollo-link-error'
import { createHttpLink } from 'apollo-link-http'

// ...

const errorLink = onError(args => {
	if (args.graphQLErrors && args.graphQLErrors.length === 1) {
		args.response.errors = args.graphQLErrors.concat(new GraphQLError(''))
	}
})

class XXXBinding extends Binding {
	constructor(uri: string) {
		const schema = makeRemoteExecutableSchema({
			schema: fs.readFileSync(schemaPath, 'utf-8'),
			link: errorLink.concat(
				createPersistedQueryLink().concat(createHttpLink({ uri, fetch }))
			),
		})
		super({ schema })
	}
}

[maticzav]

Hey @almostprogrammer 👋,

Thank you for filling the issue. Could you provide me with a small reproduction repository or CodeSandbox? That way I can find the bug a lot more quickly.

[ghost]

Hi @maticzav here's the reproduction https://github.com/almostprogrammer/graphql-binding-173-reproduction/tree/master

[maticzav]

Hey @almostprogrammer 👋,

It seems like this issue stems from graphql-tools. Would you mind opening up the issue there and reference this one? We can keep this one open as an indicator. Currently, graphql-binding doesn't opinionate error handling and we would like to keep it that way. Having graphql-tools team sort this out would benefit us greatly.

Hope you understand 🙂

[yaacovCR]

You could consider switching within graphql-binding to graphql-tools-fork, where this bug has been fixed.

[maticzav]

@yaacovCR why is the fork not merged into the official graphql-tools yet?

[yaacovCR]

Not for me to say, would love it!

[maticzav]

Is there an open PR?

[yaacovCR]

I stopped submitting PRs as they were not reviewed. I have not seen the maintainers give input on any issues in quite a while. That is why I created the fork.

You could almost say that the project was abandoned, however there was a recent PR, possibly from someone internal to Apollo, that was submitted and merged within about a day.

All kind of mysterious. Probably has something to do with Apollo's move from schema stitching to federation, but I think that there would be no downside to fixing some of these bugs...

[maticzav]

Could you try opening a PR nevertheless?

[yaacovCR]

I do not feel that it would be worth it, as I do not sense the upstream repository maintainers are interested. The code is public, though, so if you feel differently, please fork my fork and submit.

Most of the work for the PR would probably involve making sure the changelog is up to date with the bugs fixed in the expected format.

From what I have kept track, the fork addresses graphql-tools issues 454, 480, 819, 862, 997, 1048, 1056, 1061, 1074, 1075, 1121, 1147, 1159, and 1171.

[yaacovCR]

Anyways:

ardatan/graphql-tools#1206

[Urigo]

Thank you for reporting.

In the last few months, since the transition of many libraries under The Guild's leadership, We've reviewed and released many improvements and versions to graphql-cli, graphql-config and graphql-import.

We've reviewed graphql-binding, had many meetings with current users and engaged the community also through the roadmap issue.

What we've found is that the new GraphQL Mesh library is covering not only all the current capabilities of GraphQL Binding, but also the future ideas that were introduced in the original GraphQL Binding blog post and haven't come to life yet.

And the best thing - GraphQL Mesh gives you all those capabilities, even if your source is not a GraphQL service at all!
it can be GraphQL, OpenAPI/Swagger, gRPC, SQL or any other source!
And of course you can even merge all those sources into a single SDK.

Just like GraphQL Binding, you get a fully typed SDK (thanks to the protocols SDKs and the GraphQL Code Generator), but from any source, and that SDK can run anywhere, as a connector or as a full blown gateway.
And you can share your own "Mesh Modules" (which you would probably call "your own binding") and our community already created many of those!
Also, we decided to simply expose regular GraphQL, so you can choose how to consume it using all the awesome fluent client SDKs out there.

If you think that we've missed anything from GraphQL Binding that is not supported in a better way in GraphQL Mesh, please let us know!

---

In the context of that particular issue - thanks to the awesome work of @yaacovCR , GraphQL Mesh uses the new schema stitching introduced in GraphQL Tools v6.

We're looking forward for your feedback of how we can make your experience even better!