Access to event id for display

[heymackey]

I noticed on the Sentry web app, when an exception is raised, it displayed the event id as part of the error page, and I thought it would be nice to include in my Rails app.

I know if Raven.capture_exception is manually called, you have access to the ID, but was wondering if the automatic Rails exception handling provided by this library exposes that event id to include in a page render. Is it possible to get access to the event id when rendering dynamic error pages within Rails (via the config.exceptions_app)?

It seems that the only thing that is exposed is the exception according to Rails (via env['action_dispatch.exception']), but the Raven/Sentry event seems to already be fired and forgotten by that point.

** [Raven] Sending event [[EVENT_ID]] to Sentry
** [Raven] Raven HTTP Transport connecting to https://app.getsentry.com

1: class ErrorsController < ApplicationController
    2:   def not_found
    3:     render status: 404
    4:   end
    5:
    6:   def internal_server_error
    7:     byebug
=>  8:     render status: 500
    9:   end
   10: end

# don't have access to the [[EVENT_ID]] here
env['action_dispatch.exception']
#<ActionView::Template::Error: undefined method ...>

Any help or pointing to the right documentation would be incredibly appreciated!

[dcramer]

I'm wondering what a good standard approach is here. We can easily make clients remember the last eventID (which is more or less how we do this in Django). Then you can do client.getLastEventId()

[nateberkopec]

Worth wondering how this will interact with async delivery.

[heymackey]

My first thought was to stick it in the env or session with something env['sentry.exception']. The async delivery throws that approach off though, as the originating request response could have been already sent. My concern would be thread-safety in those cases, though my experience with env/session is fairly limited at this point.

I did see another issue (#204) with someone asking a similar thing about sending event info to another service, which might be the solution for async delivery, reasoning that if you're doing async already, you're not worried about the response to be handled in-band

[dcramer]

Actually yeah, if (at least) in the case where we capture this with Rack middleware we add something like sentry.event-id to the env context that would greatly help that situation. It would make a lot of sense there, as likely you're hitting a hard 500, thus rendering the error page which you'd want to show this. This is also fairly important with our user reports stuff (still in early adopter phase).

[heymackey]

That sounds pretty awesome!

[seanlinsley]

That user report modal looks great. I'd love to have that in my app 😸

[dcramer]

@seanlinsley https://gist.github.com/dcramer/4c09e4e903791cb58dbc (see link in comments if you're on dotcom and want access)

[nateberkopec]

Merged with #493