Exception Handling in Production

[mcansky]

Exception Handling in Production

[kaikuchn]

There's a snippet in the making that may be just what you need: hanami/snippets#10

[DangerDawson]

I noticed that we were getting 500 errors, and not receiving any Honeybadger notifications for certain scenario’s in production. I plan to look into this later this week and see if I can pin point the problem, and report back.

…

On 18 Dec 2019, at 16:01, Kai Kuchenbecker ***@***.***> wrote: @DangerDawson <https://github.com/DangerDawson> do you have the same problem? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#287?email_source=notifications&email_token=AAARNDFAI5XPULPMLAQJAX3QZJCOFA5CNFSM4GYVVQGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHGTDCQ#issuecomment-567095690>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAARNDF3FAOQSK6RUMOLUDDQZJCOFANCNFSM4GYVVQGA>.

[jodosha]

@mcansky I'm sorry about the confusion. I see two problems here: 1. the expectations regarding this feature 2. how to make it work.

---

Let me first clarify the goal of exception handling feature. It's meant to catch an exception and turn it into a HTTP error status (usually 4xx). Because it's managed (aka expected), you usually don't want to report it to Sentry, but sent unmanaged (aka unexpected) exceptions instead.

This is the typical usage of the feature. If you still want to send to Sentry all the exceptions, even the ones caught via handle_exception, I suggest to have a look at this paragraph: https://guides.hanamirb.org/actions/exception-handling/#custom-handlers

Via a custom handler you can manually send exceptions to Sentry: https://docs.sentry.io/clients/ruby/#reporting-failures

class MyAction
  include Hanami::Action
  handle_exception FooError => :handle_foo_error

  def call(params)
    # ...
  end

  private

  def handle_foo_error(exception)
    Raven.capture_exception(exception)
    status 400, exception.message
  end
end

If you need to handle FooError across all the actions, you can share the handling like this: https://guides.hanamirb.org/actions/share-code/

---

Now getting back to your exception raised from Redis. How's your code looking like?

[mcansky]

thanks both for your answer, I think indeed there is a bit of confusion about what we all mean and expect.

Let me take a clearer example.

Let's say we add a feature that does some work with an API, pull some data in as JSON, unmarshall it into objects and .. boom, for some reason the data in the JSON isn't as expected and an exception is raised because the code was never meant to handle this case (yet).

So yes, that refers to unmanaged exceptions.
I have tried adding a module and using the application configuration to get all the actions to include a custom method to call with handle_exception StandardError => :handle_errors but that's to no avail. Exceptions happening don't bubble up and I am still left with a 500.

So I guess my issue is more with making sure exceptions triggered through an action and within methods and libs called by the actions do bubble up to Sentry for triage, inspection, and fix. And I would expect that things happening in the view and template also can be caught and passed to sentry if it's an unexpected exception.

here is the extract from apps/web/application.rb

controller.prepare do
        include RavenHanami

        handle_exception StandardError => :capture_exception
end

and the module :

module RavenHanami
  private
  def capture_exception(exception)
    LOGGER.info("!!!!! EXCEPTION Caught for Raven/Sentry !!!!!")
    Raven.capture_exception(exception)
    redirect_to '/'
  end
end

is there something missing ?

[kaikuchn]

I'm confused about this:

Exceptions happening don't bubble up and I am still left with a 500.

If the exception does not bubble up, then it must be handled by someone and you would not get a 500. The fact that you get a 500 page shows that Hanami is handling the exception at the controller level.
It just seems like your custom handler is not triggered..
But your code looks fine. Maybe the exception you're raising isn't a kind of StandardError?

Also make sure that - if you're testing this in development - you configured this in your application.rb:

    configure :development do
      handle_exceptions true
    end

[mcansky]

@kaikuchn : most exceptions in Ruby and its frameworks are inheriting from StandardError afaik, so that should go ok (I suppose ?).

I will do another round of checks ... and report back.

[jodosha]

@mcansky 👋 any news on this?

[DangerDawson]

@mcansky Did you manage to solve this?

[kaikuchn]

@DangerDawson do you have the same problem?

[mcansky]

apologies everyone it looks like I moved on into another project and could not report back;

[DangerDawson]

So I have got to the bottom of what is happening, any exceptions being raised in the controller produces both a stack_trace and send the exception message to HoneyBadger, although if the exception happens in the view object it does not.

Is this expected behaviour?

[kaikuchn]

Docs say this:

Handle the given exception with an HTTP status code.

When the exception is raise during #call execution, it will be
translated into the associated HTTP status.

However, as can be seen in Callable the Rack response is prepared outside of the rescue block. And the result of Action#call is passed into the renderer when using a full stack hanami app.
I.e., the view is rendered only after the action finished executing. (See here, middleware would be the action in most cases.)

Anyway, IMHO this is not very user-friendly. As a user I'd expect exception handling for an endpoint to handle all exceptions that happen when hitting that endpoint, as long as it occurs in user code. As a user I would be very surprised that exceptions in views/templates are not handled.

WDYT? @jodosha

[DangerDawson]

So it looks as though this PR #866 is responsible for the behaviour I am witnessing, specifically this line.

I managed to solve my specific issue by inserting the HoneyBadger middleware in my config.ru

require './config/environment'

use Honeybadger::Rack::ErrorNotifier
run Hanami.app

Although I still find the behaviour confusing that exceptions in the view are handled differently from those that manifest in the controller / services / etc.

[DangerDawson]

Any update on this?

Although I am able to receive exceptions in Honeybadger, I do not have any context, and the logs do not provide any stacktrace either.

Like I said, this is completely different behaviour from any exceptions happening before the view rendering e.g. services / controllers, which do provide a full stacktrace and context.

[tadejm]

We also struggled getting exceptions reported to Rollbar. They were reported for anything job related but not for request. Something was preventing the exception to bubble up so we ended up setting handle_exceptions false for production and fixed it.

[DangerDawson]

We ended up fixing this by putting the rack middleware in config.ru e.g.

use Honeybadger::Rack::ErrorNotifier
use Honeybadger::Rack::UserFeedback
use Honeybadger::Rack::UserInformer

[cllns]

I got an email notification for someone posting a comment on this thread, which it seems like they have deleted. Not going to tag them since they deleted it for a reason, but I think the comment is a helpful piece of feedback:

I agree that the default behavior is confusing and ends up being a really bad UX, since the defaults make it so your error reporting system doesn’t see 500s in production. All unhandled exceptions should go to error reporting system, yet we should be able to render custom views for these errors.

I think we’re going to have to monkeypatch this behavior for now 😞

[jodosha]

Closing as stale. Feel free to reopen, in case.

[mcansky]

so @jodosha , what's the way to handle exceptions towards an exception tracker ?

I guess the "simplest" is to plug into https://github.com/hanami/controller#exceptions-management

has a standard way to do so in an Hanami app been documented ?