We'll need to implement these final two methods (in the top level client) to conform to the expected Raven API:

• Raven.captureMessage('message')
• Raven.captureException(exception)

I think I found a bug. On the readme it says "By default events will be sent to Sentry in all environments except 'test', 'development', and 'cucumber'. "

On my app, I needed to explicitly specify the staging environment, for raven to work. Something like this:

config.environments = %w[ production staging ]

Maybe you need to fix, either the readMe or the gem :p

Have a nice day!

Sentry supports information about the authenticated user via the sentry.interfaces.User interface. However, raven-ruby does not implement this interface. Looking at the current code, I'm not sure how to implement it either.

I see how interfaces are defined and how they are appended to the data sent to sentry,

@interfaces.each_pair do |name, int_data|
  data[name] = int_data.to_hash
end

but the initialization of the interfaces is hard coded inside the capture_exception and capture_rack_exception making it difficult to add additional interfaces. It seems a better approach would be to allow each interface to initialize itself inside its own constructor. The capture_exception would then look something like this,

def capture_exception(exception, context = {}, configuration = nil, &block)
  configuration ||= Raven.configuration
  if exception.is_a?(Raven::Error)
    # Try to prevent error reporting loops
    Raven.logger.info "Refusing to capture Raven error: #{exception.inspect}"
    return nil
  end
  self.new do |event|
    Raven.interfaces.each_pair do |name, interface|
      event.interfaces[name] = interface.new(exception, context, configuration)
    end
    block.call(evt) if block
  end
end

This evening my api got taken got down by user who's sending me ~200 request a minute all of a sudden those requests were sending null for a required parameter which caused an exception. Having to send all those exceptions to get sentry brought my server down.

It would be nice to be able to say, "don't send more than x in a second, and on top of that don't send more than y in an hour": if I see more than 100 exceptions in get sentry I don't care if its 100 or 100K its an issue I've got to look at.

This has also come up in raven-js

getsentry/sentry-javascript#92

I'm not sure if it should be on raven or sidekiq.

bugsnag created a middleware: https://github.com/bugsnag/bugsnag-ruby/blob/master/lib/bugsnag/sidekiq.rb

In Python we allow you to say "stack=True" on any capture method to pull down the current stacktrace.

It looks like Ruby supports this as well, and it'd be a useful addition:

http://stackoverflow.com/questions/11122233/get-current-stack-trace-in-ruby-without-raising-an-exception

We're using the hosted getsentry service. When an error happens in Rails, it includes the Request. However, when we rescue an error and use Raven.capture_exception, we're not seeing the Request section in getsentry.

Whether automatic or just better documented in the README, either would be fine. Thanks!

We need a full integration test showing that the Rails middleware is actually functioning in various versions

There may be reasons this doesnt make sense, but what do we have to do to enable gzip by default, and what potential caveats are there?

(Ruby has some of the larger exceptions out of most platforms, so having gzip on would help quite a bit)

The installation instructions say to add this to the Gemfile:

gem "sentry-raven", :git => "https://github.com/getsentry/raven-ruby.git"

And this in an initializer:

require 'raven'

Raven.configure do |config|
  config.dsn = 'http://public:[email protected]/project-id'
end

But this will result in zero exceptions getting logged. Requiring 'raven' in an initializer is too late; by that point, Rails is already halfway through running initializers, and the initializer that Raven::Railtie tries to install -- the one that inserts the middleware -- will never be run.

Two possible ways to solve this problem:

• Instruct people to use the following in the Gemfile (note the added :require option):

gem "sentry-raven", :git => "https://github.com/getsentry/raven-ruby.git", :require => "raven"

• Add a sentry-raven.rb file to the gem that just does require 'raven' (and remove the require 'raven' line from the initializer). Such a file will be required automatically during the Rails/Bundler boot sequence. I recommend this approach, as it requires less configuration by the user.

We need to implement an exponential timed backoff for server failures.

raven-python has a reasonable basic implementation that we can just copy/paste

Currently when an exception is raised I'm unaware of what environment it is coming from. It would be excellant to be able to configure tags upfront to include the current environment in it.

Raven.configure do |config|
  config.tags => {
    'environment' => 'production',
  }
end

Alternatively simply setting this as a default for the client would make sense in my mind unless I'm missing some way of doing it already ( on a client scale not per exception scale ) or missing where it is on the individual exception page.

Hi,

I was wondering if there was any way that I can configure raven/Sentry to hold on to some Rails-y data. I would love to have params, session, cookies, and env alongside every error on your dashboard as it substantially cuts down debugging time.

Any way of doing this?

Thanks!

Env:
rails 3.2.11
sentry-raven 0.4.8

sentry server 5.4.5

We are testing a production environment.
Sentry-raven not caching or sending exceptions after server errors.

sentry-raven 0.4.8
Completed 500 Internal Server Error in 1111ms

sentry-raven 0.4.5
Completed 500 Internal Server Error in 1111ms
** [Raven] Sending event 4055553156e548d589acca7ca6c57dd8 to Sentry
** [Raven] Raven HTTP Transport connecting to http://blablabla.local:9000

filter_parameters is the Rails interface to avoid logging sensitive parameters. raven-ruby's Rails integration should integrate it with the data sanitizer.

I have two environments, production and staging. I'd like to distinguish between those two using colors, so for production the level would be error and for staging - warning. As I checked currently there is no way to set level globally - any ideas how to achieve visual separation?

I've created a fork which I think provides support for legacy Rails 2.3 applications. See here:
https://github.com/aaronrussell/raven-ruby/tree/rails-2.3

I've only spent a few hours tinkering with the code, it's completely untested and it's playing around with parts of Rails I'm not very familiar with, so I'm reticent to send a pull request just yet.

I wondered if anyone would be willing to help by trying the fork in their legacy apps and reporting any issues? If good, I can send the pull request.

gem "sentry-raven", :git => "git://github.com/aaronrussell/raven-ruby.git", :branch => "rails-2.3"

When an object containing circular references is passed as an :extra oj crashes after exhausting all of the available stack space.

Would it be possible for the default SanitizeData to utilize config.filter_parameters from Rails when in a Rails app.

I see that it filters 16-digit numbers for credit cards, but it doesn't cover things like CCV/CSCs out of the box.

Reports of Sinatra not working with default Rack example. Need to investigate further.

This code worked:

https://gist.github.com/3823315

When using the UDP protocol, in a standard Rails application (rails console), I get the following output:

irb(main):002:0> Raven.capture { 1 / 0 }
Errno::EMSGSIZE: Message too long - send(2)
    from /Users/remon/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/bundler/gems/raven-ruby-d9852a74fa1f/lib/raven/transports/udp.rb:13:in `send'
    from /Users/remon/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/bundler/gems/raven-ruby-d9852a74fa1f/lib/raven/transports/udp.rb:13:in `send'
    from /Users/remon/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/bundler/gems/raven-ruby-d9852a74fa1f/lib/raven/client.rb:32:in `send'
    from /Users/remon/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/bundler/gems/raven-ruby-d9852a74fa1f/lib/raven.rb:78:in `send'
    from /Users/remon/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/bundler/gems/raven-ruby-d9852a74fa1f/lib/raven.rb:111:in `capture_exception'
    from /Users/remon/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/bundler/gems/raven-ruby-d9852a74fa1f/lib/raven.rb:95:in `rescue in capture'
    from /Users/remon/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/bundler/gems/raven-ruby-d9852a74fa1f/lib/raven.rb:90:in `capture'
    from (irb):2
    from /Users/remon/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/railties-3.2.12/lib/rails/commands/console.rb:47:in `start'
    from /Users/remon/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/railties-3.2.12/lib/rails/commands/console.rb:8:in `start'
    from /Users/remon/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/railties-3.2.12/lib/rails/commands.rb:41:in `<top (required)>'
    from script/rails:6:in `require'
    from script/rails:6:in `<main>'

Resulting in the exception not be captured at all. Is there some sort of max_message size I should increase to get this working?

It would seem Raven.captureException is the fundamental API to do custom notification outside of the middleware. It feels wrong to write that in my idiomatic Ruby application code due to the camel-case. Can you at least alias these methods to capture_exception and capture_message as Event does?

what we should do to support rails 2?

Event's dont yet support specifying tags

When you're using the environment variable to configure the client (SENTRY_DSN) you shouldn't be required to call Raven.configure with an empty block.

Allow the client to be configured to ignore certain exceptions when its setup to capture via the middleware.

An example is Rails routing errors.

They currently only support the exception/message args

It would be helpful to allow the application to make some extra data available that would be logged along with the stack trace. For example, the currently logged in user. ExceptionNotification does this through the request.env (see https://github.com/smartinez87/exception_notification "Customization" section)

Since there is currently no session attribute on the Http interface, a temporary solution would be to include the Rails session info as a special cookie named "RailsSession" when sending the Http interface data to Sentry.

A more permanent solution would be to add a session attribute on the Http interface, since most web frameworks support this functionality and would benefit from having this attribute.

I'm using Sinatra, and my list of exceptions seem to be ignored by sentry.

  Raven.configure do |config|
    config.dsn = ENV['SENTRY_DSN']
    config.environments = %w[staging production]
    config.excluded_exceptions = [
      Rack::OAuth2::Server::Abstract::Error,
      Rack::OAuth2::Server::Resource::Bearer::Unauthorized,
      Rack::OAuth2::Server::Resource::Bearer::Forbidden
    ]
  end

There are various issues with handling of errors caused by broken UTF-8 strings. I've tried these scenarios in a Sinatra app.

1. Exception message with invalid UTF-8 data

raise RuntimeError.new("\xC3".force_encoding('UTF-8'))

Produces Error from Sentry server (403): Bad data reconstructing object (UnicodeDecodeError, 'utf8' codec can't decode byte 0xc3 in position 14: unexpected end of data))

2. Rack environment with invalid UTF-8 data

# simulate bad input
env['REQUEST_URI'] = "\xC3".force_encoding('ASCII-8BIT')
# raise an exception
1 / 0

Raven::Event.capture_rack_exception produces an exception when serializing Rack input as JSON.

Relevant code

require 'raven'
Raven.configure do |config|
  config.dsn = 'https://####@app.getsentry.com/####'
  config.environments = %w[development production]
end

# ...

error do
  evt = Raven::Event.capture_rack_exception(env['sinatra.error'], env)
  Raven.send(evt) if evt
end

From time to time, I get the following error in raven client
"
raven/client.rb in rescue in send
NameError: undefined local variable or method `logger' for #Raven::Client:0xb8e5a84
"

It appear that the culprit is the line 36 of client.rb
logger.error "Unable to record event with remote Sentry server"

It should be fixed by using:
Raven.logger.error "Unable to record event with remote Sentry server"

https://gist.github.com/3c7056b03d62ba415015

I'm looking at using Sentry with Sidekiq however I'm not using Sidekiq within a Rails / Rack environment.

It seems like there is no way to set an environment from some other source aside from RACK_ENV or RAILS_ENV, neither of which are appropriate env's to be set for background processing.

Would it be possible to ease up the current_environment to allow for overrides?

Just spent a few minutes here trying to figure out why setting config.current_environment wasn't working and I found out that the feature was added without a version bump, so even though I was using the latest version 0.2, I had to update to fix it.

The timeouts (timeout and open_timeout) for the Faraday requests should be configurable through Raven's configuration.

We should probably just send the actual version numbers (rather than the entire hash) for modules:

http://cl.ly/1D163S1l2F0C2C2b0G1b

It should be easier to capture Http information.

Two improvements we could make:

1. Add a context helper to globally set the env context

   Raven.rack_context(env)

2. Add a way to specify the env as part of the options:

   Raven.capture_message('message', :rack_env => env)

Sentry seems to fail if a newer version of Hashie is not available.

I have some Hashie 1.0.0 dependencies, and trying to run bin/raven fails. If I remove those dependencies and update Hashie, the script runs fine.

bundle exec raven test https://sentryaddresshere.host
Sending test event
/Users/dev/project/bundle/ruby/1.9.1/gems/sentry-raven-0.4.5/lib/raven/interfaces.rb:17:in `assert_required_properties_set!': super: no superclass method `assert_required_properties_set!' for #<Raven::ExceptionInterface:0x007fea3902b5e0> (NoMethodError)

This might only be a problem in development mode, but the latest Rails 3 version worked just fine when I had originally tested it.

Manually throwing this into the raven.rb initializer makes everything behave properly:

Rails.configuration.middleware.use "Raven::Rack"

On 1.9.2 and 1.9.3 this can be done easily using the binding_of_caller gem.

Example monkey patch:

require 'binding_of_caller'

module Kernel
  original_raise = method(:raise)
  define_method(:raise) do |*args|
    begin
      original_raise.call(*args)
    rescue Exception => e
      e.instance_variable_set(:@stack_info, binding.callers)
      e.set_backtrace(e.backtrace.drop(2))
      original_raise.call(e)
    end
  end
end

On 1.8.7 this could be possibly be done using the continuation tracing hack outlined in http://rubychallenger.blogspot.com/2011/07/caller-binding.html

As you can check of event.rb on both function capture_exception or capture_message the level it's always setted to :error, and doesn't take care about the :level value on the options.

event.rb line 137

def self.capture_message(message, options={})
      new(options) do |evt|
        evt.message = message
        **evt.level = :error**
        evt.interface :message do |int|
          int.message = message
        end
      end
    end

and the same on line 111

the sentry-raven.gemspec is asking faraday 0.8.0 rc2

 gem.add_dependency "faraday", "~> 0.8.0.rc2"

While reading the faraday's changelog the 0.8 version seems to only impact get, head, delete https://github.com/technoweenie/faraday/wiki/Changelog.

Can the requirements to faraday be >=0.7.6? Lots of projects have not stepped to 0.8. This could avoid conflicts in Gemfile. raven-ruby doesn't need the 0.8 version (I've ran the raven-ruby tests in 0.7.6 and they all passe)

regards

yajl-ruby does not compile in jruby.

On a mixed environment like ruby, python, java, etc I think XML works better.

If JSON is the best choice for raven-ruby, we could use something like multi_json and let developer decide which json library he want.

What do you think?

I can make a pull request if you accept the change to multi_json :)

This should probably include a transport abstraction in the client.

Currently it marks all frames as in application in many conditions.

For example, one app their entire code has absolute paths that are all like /app/foo/XXX/...

The solution is likely to add in a source root configuration option, and when that is set prepend the app detect with that path.

(We should also remove the absolute detection in in_app, and only check for relative app/* etc paths)

Can't help getting the following error while deploying to Heroku. Annyone had problems with this?

Running: rake assets:precompile
rake aborted!
bad URI(is not URI?):
/tmp/build_vv803j0m3xxr/vendor/bundle/ruby/1.9.1/gems/sentry-raven-0.4.5/lib/raven/configuration.rb:83:in server=' /tmp/build_vv803j0m3xxr/config/initializers/raven.rb:4:inblock in <top (required)>'
/tmp/build_vv803j0m3xxr/vendor/bundle/ruby/1.9.1/gems/sentry-raven-0.4.5/lib/raven.rb:64:in `configure'

Running Ruby 1.9 and Rails 3.2.13