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

Added logging to the default error formatter #251

Merged
merged 4 commits into from Aug 15, 2020

Conversation

mcollina
Copy link
Collaborator

As titled

@paolochiodi
Copy link
Contributor

Tested, and it works.

But should the logging be part of the error formatter?

Seems like a side effect that may not be evident to users, and thus they'd fail to reimplement it when they use a custom formatter.
I think logging should be a separate step unrelated to formatting.

lib/errors.js Outdated
@@ -74,13 +83,15 @@ function defaultErrorFormatter (err) {
}).reduce((acc, val) => acc.concat(val), [])
}

return {
const res = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't we just return here?

@mcollina
Copy link
Collaborator Author

Seems like a side effect that may not be evident to users, and thus they'd fail to reimplement it when they use a custom formatter.

This come from experience. There is a significant amount of devs that asked for a similar feature to be removed from Fastify. If I move it outside of the errorFormatter, I would need to add a new option. By putting it in the errorFormatter, I leave it to the user by default.

@paolochiodi
Copy link
Contributor

Seems like a side effect that may not be evident to users, and thus they'd fail to reimplement it when they use a custom formatter.

This come from experience. There is a significant amount of devs that asked for a similar feature to be removed from Fastify. If I move it outside of the errorFormatter, I would need to add a new option. By putting it in the errorFormatter, I leave it to the user by default.

Yeah, but then you force devs that don't want the logs to rewrite the error formatter. To me the two features should just not be linked.

@pscarey
Copy link
Collaborator

pscarey commented Aug 15, 2020

In terms of logging in the error formatter, we re-implemented the error formatter with logging & error capturing (i.e. Sentry) only for specific errors which are unrecognised.

I'd argue that the default error formatter is intended for development or basic requirements, but anyone who's running a production env will quite likely want to capture & report errors. Fastify itself also logs requests out.

Possibly the errorFormatter could be re-concieved as e.g. a series of onGraphQLError hooks, but that's probably beyond the scope of this change.

I do get the argument that it could possibly be clearer, or there could be more options, but I'd also argue that it's still a net positive change this way, and further updates can be made.

@mcollina mcollina merged commit 35c8252 into master Aug 15, 2020
}

function maybeFormatErrors (execution, reply) {
function maybeFormatErrors (execution, context) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mcollina could you update the index.d.ts definition of errorFormatter? Very coincidental timing on your PR but I'm just now trying out/setting up fastify-gql and wanted to access the context from my error logging. :-) Thanks!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you have time to send a PR, it'd be quicker.

@simoneb simoneb deleted the default-error-formatter-logging branch April 25, 2022 11:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants