-
Notifications
You must be signed in to change notification settings - Fork 140
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
Errors not being handled #376
Comments
Hey @mozcomp I think this is a (recently) known issue I've been meaning to speak to @wagenet about. Basically @wagenet not sure if you'd be able to take a look at this? Otherwise it is on my radar but not sure exactly when I'll get to it. |
@mozcomp this actually looks to be an error in the status = ActionDispatch::ExceptionWrapper.rescue_responses[exception_class_name] which is really a private interface...the public one (which we support) would be status = ActionDispatch::ExceptionWrapper.status_code_for_exception(exception_class_name) This is what Rails itself does. So the bug is really lograge using a private interface instead of the public one. Until I can PR to lograge, you can monkey-patch to fix this: Lograge::LogSubscribers::Base.class_eval do
def get_error_status_code(exception_class_name)
ActionDispatch::ExceptionWrapper.status_code_for_exception(exception_class_name)
end
end |
Hi Lee, Thanks for the prompt reply ... The backtrace on the error now looks like this
I hope this helps, as you're delving into areas I have no idea about.. |
@mozcomp that actually looks correct to me - we raise the error |
I must admit I wasn't expecting the backtrace to be surfaced on the console, it wasn't in the employee_directory example. So, I then want back to the starting point to find which action allowed the completion of the request, and of course found your original fix - the monkey-patch to lograge did the job. Many thanks |
Fantastic, thanks @mozcomp 🎉 ! |
@mozcomp we have a very similar error to @richmolj. Although we tried the suggested monkey-patch for Lograge, but it still reports an error to Honeybadger. We get this output in our logs, as expected:
Our controller calls: raise Permissions::AccessDenied And our base controller registers the exception: register_exception Permissions::AccessDenied,
status: 403,
title: "Access denied",
handler: Graphiti::Rails::ExceptionHandler Is there any way to prevent the Honeybadger from being raised when using |
Registered errors like Graphiti::Errors::RecordNotFound aren't being handled as I'd expect.
The json formatted error is rendered, but still surfaces as an error on the server such that they're being reported by system-wide error handler HoneyBadger. Or is this as expected?
Running example Employee Directory the console reports a RecordNotFound ...
But in my app it returns what I would call an unhandled error ..
My real problem is because it's handled "magically" in graphiti-rails, there's not a lot I can see to configure or change.
What should I be looking for?
The only "unusual" thing about the app is that it was created as a number of Rails Engines to provide a degree of modularity, and as such the API is an engine with an isolated namespace .. /api.
Admittedly, my app is still Rails 5.1, and the example is 5.2, but I can't see that being the difference.
Any suggestions would be appreciated.
The text was updated successfully, but these errors were encountered: