Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

throw from resolver should not be logged #199

Closed
marktani opened this issue Mar 2, 2018 · 21 comments
Closed

throw from resolver should not be logged #199

marktani opened this issue Mar 2, 2018 · 21 comments
Assignees
Labels
kind/discussion Discussion, question or feedback

Comments

@marktani
Copy link
Contributor

marktani commented Mar 2, 2018

@steida commented on Mon Feb 26 2018

Maybe I am wrong, but

const throwError = (error /*: ServerError */) => {
  throw new Error(JSON.stringify(error));
};

const throwNotAuthorizedError = () => throwError({ type: 'notAuthorized' });

Seems to be a recommended way how to stop resolver, but then probably this should not be logged.

screen shot 2018-02-26 at 02 03 45

@schickling
Copy link
Contributor

Thanks a lot for bringing this up @steida. If I'm not mistaken then it's actually not graphql-yoga which implements the error logging but one of the underlying GraphQL libraries (I guess apollo-server-express). We should dig a bit deeper into this and see where the logging originates.

Do you want a setting to disable error logging or rather an easy way to catch all of these errors and implement your own handling?

@steida
Copy link

steida commented May 21, 2018

@schickling Own handling, definitely. Do you have any idea how?

@schickling
Copy link
Contributor

@timsuchanek @divyenduz can you describe a couple of approaches here?

@danutzcodrescu
Copy link

danutzcodrescu commented Jun 23, 2018

@steida you can install apollo-errors package and then implement your own errors. You can implement your custom errors like it is presented in Apollo documentation

@steida
Copy link

steida commented Jun 23, 2018

Actually, I moved all errors to the schema where it belongs. And https://github.com/maticzav/graphql-shield soon allow controlling logging I guess.

@steida
Copy link

steida commented Jun 23, 2018

@schickling Feel free to close it. Thank you.

@johannpinson
Copy link

Hello @danutzcodrescu

After seen your comment, I also looked about this one #167

After make some test by adding apollo-errors (unofficial) to my project, I didn't get more information inside the error object in the response .
Actually, it seems we need to use directly apollo-server-errors (official) and extend ApolloError class.

@rvlewerissa
Copy link

@johannpinson Hi, how do you manage to make the error response log disappears?

I tried the following:

import {ApolloError} from 'apollo-server-errors';

// and in resolver
throw new ApolloError('Not Authorized!');

doesn't work..

@johannpinson
Copy link

hey @rvlewerissa

Actually I reviewed my workflow and I use Apollo Server v2 directly, so I didn't have even more this problem 😉

@rvlewerissa
Copy link

@johannpinson Ah I see.. Thanks

@samuela
Copy link

samuela commented Nov 15, 2018

I'd like to vote against this actually, or at least for a modified version. This has the very unfortunate side effect of hiding "legitimate" errors, without any record of them. That makes things extremely hard to reproduce and debug when fit hits the shan. It seems to me that the ideal way to cover this would be to skip logging on certain classes of Errors (NotAuthorizedError and so on), but maintain logs for all others. I really want to know why things aren't working when my database fails to connect, my resolver logic is flawed, or a third-party package misbehaves.

@MohamedElmdary
Copy link

@marktani if you still facing this problem you need to add debug: false in start options

const options = {
  port: 8080,
  endpoint: "/graphql",
  subscriptions: "/subscriptions",
  playground: "/playground",
  formatError(err: any): any {
    return err.message;
  },
  debug: false // this would prevent logs
};

server.start(options, () => {
  console.log("server started!");
});

@rista404
Copy link

rista404 commented Jan 18, 2019

@samuela I had the some problem, and the following did the job for me:

import {
	isInstance as isApolloErrorInstance,
	formatError as formatApolloError,
} from 'apollo-errors'

export default function formatError(error) {
	const { originalError } = error

	// Skip logging Apollo controlled errors
	if (isApolloErrorInstance(originalError)) {

		// Maybe do stuff with apollo error

		return formatApolloError(error)
	}

	// Finally, log uncontrolled errors
	console.error(error)

	return error
}

I assume all apollo errors (from apollo-errors package) are controlled, and skip logging them.

@stale
Copy link

stale bot commented Mar 19, 2019

Due to inactivity of this issue we have marked it stale. It will be closed if no further activity occurs.

@stale stale bot added the status/stale label Mar 19, 2019
@samuela
Copy link

samuela commented Mar 19, 2019

bump to unstale?

@stale stale bot removed the status/stale label Mar 19, 2019
@stale
Copy link

stale bot commented May 24, 2019

Due to inactivity of this issue we have marked it stale. It will be closed if no further activity occurs.

@stale stale bot added the status/stale label May 24, 2019
@samuela
Copy link

samuela commented May 24, 2019

bump

@stale stale bot removed the status/stale label May 24, 2019
@ken-nah
Copy link

ken-nah commented Aug 1, 2019

@marktani if you still facing this problem you need to add debug: false in start options

const options = {
  port: 8080,
  endpoint: "/graphql",
  subscriptions: "/subscriptions",
  playground: "/playground",
  formatError(err: any): any {
    return err.message;
  },
  debug: false // this would prevent logs
};

server.start(options, () => {
  console.log("server started!");
});

This worked for me.

@saihaj saihaj mentioned this issue Dec 5, 2021
32 tasks
@ardatan
Copy link
Collaborator

ardatan commented Mar 22, 2022

I think plugins from Envelop's ecosystem with error masking can be used to solve this issue;
See https://www.graphql-yoga.com/docs/features/error-masking

@ardatan ardatan closed this as completed Mar 22, 2022
@factoidforrest
Copy link

I don't see how I can call a custom handler with that. I can turn off masking, but how about doing something critically important, like logging the error? Where is the formatError function?

@ardatan
Copy link
Collaborator

ardatan commented Oct 4, 2022

You can manage error handling as described in here;
https://www.the-guild.dev/graphql/yoga-server/docs/features/error-masking

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/discussion Discussion, question or feedback
Projects
None yet
Development

No branches or pull requests