All errors in resolve are catched, making it hard to find errors

[Gregoor]

I think my problem comes down to these lines here:

graphql-js/src/execution/execute.js

Lines 554 to 556 in e41ffa5

	try {
	return resolveFn(source, args, info);
	} catch (error) {

When using this in conjunction with express every error is sent down to the client, where only the message is displayed. I really miss my stack traces... 😿

Wouldn't it be possible to only catch a certain type of error here?

[Gregoor]

I would gladly write a PR for this, if someone could just confirm (or deny) that my thinking isn't off.

[sveisvei]

I think this will solve it for you (err.originalError): #251

[Gregoor]

Not really, I think the that issue is about GraphQL losing the reference to the original error internally.

This issue is about GraphQL catching and returning every error happening in resolve. Doesn't this also have security implications, since resolve is used to communicate with data sources which might throw error's that leak info?

[Gregoor]

I'd love to work on a PR for this, if someone confirms it.
Right now it makes working and debugging a GQL endpoint kinda absurd when every error (like an undefined variable is thrown to the frontend).

[AriaMinaei]

+1

[Gregoor]

@leebyron your opinion on this would be greatly appreciated. If I'm not mistaking here I would start working on a proposal and a PR.

[Gregoor]

@leebyron I'd really like some feedback on this. Can't really work around the silence. Like I said, I'm glad to work on a proposal for a solution, but I'd like some confirmation first that I'm not missing something fundamental.

[leebyron]

I'm sorry for the delay. I think #284 is the right solution to this issue, the ability to provide a logger which is called when an error occurs, which should allow for the optional and efficient logging of errors in production with as much fine grained detail as is wanted.

I'm open to proposals on the question of performing processing on errors. So far my suggested approach has been to perform this kind of error formatting as a post-execute step outside of graphql-js and before sending the response over the network. express-graphql added this approach in graphql/express-graphql@1cefba8 which lets you provide an error post-processing function to do things like expose stack traces or sanitize potentially sensitive error messages.

[Gregoor]

Thanks for getting back to me on this. I'm glad there is a way now for me to log errors on the server-side, thanks! I'm still a bit unsure whether it is the best default to forward all server errors to the client. So maybe the default formatError should just return a generic error message?

Anyway, this issue can be considered solved from my side :)