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

Notes & Questions #5

Closed
wadetandy opened this issue May 2, 2019 · 7 comments
Closed

Notes & Questions #5

wadetandy opened this issue May 2, 2019 · 7 comments

Comments

@wadetandy
Copy link
Contributor

Wanted a place to capture random thoughts while looking over the code and also a place to address questions you ask in your comments.

@wadetandy
Copy link
Contributor Author

https://github.com/wagenet/graphiti-rails/blob/master/lib/graphiti/rails/exceptions_app.rb#L22-L23
Do we actually want to log?

This probably should depend on the specific error type? If the response is >=500, I'd think logging is appropriate. If it's something like a 400 bad request that we have gotten from our request validator, then logging is probably not necessary.

@wadetandy
Copy link
Contributor Author

https://github.com/wagenet/graphiti-rails/blob/master/lib/graphiti/rails/context.rb#L5-L10
Any downside to including this in all Rails controllers?

Would follow the lead of some other projects and have this as a configurable option:

Graphiti::Rails.configure do |c|
  c.base_controller = 'ApplicationController'
end

@wadetandy
Copy link
Contributor Author

wadetandy commented May 2, 2019

The list of errors you pulled from graphiti to merge into action_dispatch.rescue_reponses doesn't include the new InvalidRequest error, which will be one of the critical ones we need to handle.

That has a custom error handler subclass in graphti_errors: https://github.com/graphiti-api/graphiti_errors/blob/master/lib/graphiti_errors.rb#L23-L26

@richmolj
Copy link
Collaborator

richmolj commented May 2, 2019

I wrote my own notes here: https://gist.github.com/richmolj/ded6c99353ead759785caaeeb68a7e60

To touch on a few things Wade mentioned:

If the response is >=500, I'd think logging is appropriate. If it's something like a 400 bad request that we have gotten from our request validator, then logging is probably not necessary.

I think these are good defaults, we just need the ability to override with register_graphiti_exception FooError, log: false. One example is avoiding logging on 404 - maybe, maybe not. I think we have a few internal BGov errors as well were we just want to eliminate legacy noise.

Would follow the lead of some other projects and have this as a configurable option:

I'd prefer including a mixin as a little more explicit. The downside to applying to all controllers is running AMS/whatever and graphiti side-by-side.

@wagenet wagenet added this to the 1.0 milestone May 7, 2019
@wagenet
Copy link
Collaborator

wagenet commented May 7, 2019

@wadetandy for now, I think we'll only log fatal exceptions. See eeb6b6d.

@wagenet
Copy link
Collaborator

wagenet commented May 7, 2019

See also #7

@wagenet
Copy link
Collaborator

wagenet commented May 7, 2019

For easier discussion, I've split these up into multiple issues. If I missed anything, please open a new issue.

@wagenet wagenet closed this as completed May 7, 2019
@wagenet wagenet removed this from the Release 0.1 milestone May 7, 2019
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

No branches or pull requests

3 participants