bugsnag/bugsnag-ruby

BugSnag error monitoring & reporting software for rails, sinatra, rack and ruby

Bugsnag error monitoring & exception reporter for Ruby

The Bugsnag exception reporter for Ruby gives you instant notification of exceptions thrown from your Rails, Sinatra, Rack or plain Ruby app. Any uncaught exceptions will trigger a notification to be sent to your Bugsnag project.

Features

• Automatically report unhandled exceptions and crashes
• Report handled exceptions
• Attach user information to determine how many people are affected by a crash
• Send customized diagnostic data
• Track events that occur leading up to a crash

Getting started

1. Create a Bugsnag account
2. Complete the instructions in the integration guide for your framework:
   • Que
   • Rack
   • Rails
   • Rake
   • Sidekiq
   • Other Ruby apps
   • For EventMachine integration, see bugsnag-em
3. Relax!

Support

• Read the configuration reference:
  • Que
  • Rack
  • Rails
  • Rake
  • Sidekiq
  • Other Ruby apps
• Check out some example apps integrated with Bugsnag using Rails, Sinatra, Padrino, and more.
• Search open and closed issues for similar problems
• Report a bug or request a feature

Contributing

All contributors are welcome! For information on how to build, test and release bugsnag-ruby, see our contributing guide. Feel free to comment on existing issues for clarification or starting points.

License

The Bugsnag ruby notifier is free software released under the MIT License. See LICENSE.txt for details.

bugsnag-ruby's Issues

Warning: "[Bugsnag] Overwriting request data for key rails2_request"

For testing a Rails 2.3.14 app I'm using RSpec with the help of parallel_tests, which speeds up running the specs by using parallel processes.

After upgrading my app to Bugsnag from 1.1.5 to 1.2.1 I get lots of warnings while running the controller specs:

** [Bugsnag] Overwriting request data for key rails2_request

Use middleware after Middleware::Rails3Request

I'd like to setup my bugsnag middleware after the Rails3Request middleware.

Because of the Rails3Request middleware is loaded very late (see https://github.com/bugsnag/bugsnag-ruby/blob/master/lib/bugsnag/railtie.rb#L41), the Middleware.insert_after facility is of no use. Shouldn't this bugsnag middleware be setup before initializers run, so that users get to choose if they want to run before or after it?

Underlying reason is that I don't want to forward my action_dispatch-secret_token spilled over many mail, notifications, and bugsnag pages and would like to filter it.

Don't assume the app has Rack

We'd (Minefold) would like to use Bugsnag on a few internal processes that arn't web facing. It would be nice if bugsnag/rack wasn't required by default!

Bad practice in EventMachine documentation

In your documentation of how to use the bugsnag gem with EventMachine, you use this example code:

EventMachine::run do
  server = EventMachine::start_server('0.0.0.0', PORT, MyServer)
  server.errback {
    Bugsnag.notify(RuntimeError.new("Something bad happened"))
  }
end

Calling a synchronous method like Bugsnag.notify in an error handler like this is a very bad idea, because that will block all other events from occurring. I don't expect your documentation to become a discussion of EventMachine best practices, however documenting this as the correct way to use bugsnag could be misleading. Ideally there would be an EventMachine interface for bugsnag (one of the many downsides of EventMachine), but there is a fairly simple workaround for this: wrapping synchronous calls with EM.defer:

EventMachine::run do
  server = EventMachine::start_server('0.0.0.0', PORT, MyServer)
  server.errback {
    EM.defer do
      Bugsnag.notify(RuntimeError.new("Something bad happened"))
    end
  }
end

Remove useless fake method names from stacktraces in templates

Crashes in rails templates have auto-generated, junk method names, eg:

from app/views/dashboard/plans/_details_box.slim:4:in _app_views_dashboard_plans__details_box_slim___3303598402133064902_70117896204060

These method names are enormous, and don't help at all with debugging. They look awful in our dashboards.

I propose we replace these method names with something like [template] or another placeholder.

Bugsnag missed an error, but was caught by New Relic

Hi,

We had a pretty severe error happen in our app, that was causing quite a few 500's. We think the problem was with our Heroku infrastructure, so thats a seperate issue. The thing though, was that Bugsnag didn't catch any of the errors.

Heres the stack trace from New Relic (note that Bugsnag is actually in the stack trace list):

        /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/logger.rb: 370:in `<'
        /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/logger.rb: 370:in `add'
…vesupport-3.2.13/lib/active_support/buffered_logger.rb:  80:in `add'
…ivesupport-3.2.13/lib/active_support/tagged_logging.rb:  48:in `add'
…ivesupport-3.2.13/lib/active_support/tagged_logging.rb:  54:in `error'
…ivesupport-3.2.13/lib/active_support/log_subscriber.rb:  95:in `rescue in call'
…ivesupport-3.2.13/lib/active_support/log_subscriber.rb:  92:in `call'
…port-3.2.13/lib/active_support/notifications/fanout.rb:  47:in `publish'
…port-3.2.13/lib/active_support/notifications/fanout.rb:  25:in `block in publish'
…port-3.2.13/lib/active_support/notifications/fanout.rb:  25:in `each'
…port-3.2.13/lib/active_support/notifications/fanout.rb:  25:in `publish'
….2.13/lib/active_support/notifications/instrumenter.rb:  25:in `instrument'
…tivesupport-3.2.13/lib/active_support/notifications.rb: 123:in `instrument'
…-3.2.13/lib/action_controller/metal/instrumentation.rb:  27:in `process_action'
…k-3.2.13/lib/action_controller/metal/params_wrapper.rb: 207:in `process_action'
….2.13/lib/active_record/railties/controller_runtime.rb:  18:in `process_action'
…gems/actionpack-3.2.13/lib/abstract_controller/base.rb: 121:in `process'
…actionpack-3.2.13/lib/abstract_controller/rendering.rb:  45:in `process'
…/gems/actionpack-3.2.13/lib/action_controller/metal.rb: 203:in `dispatch'
…-3.2.13/lib/action_controller/metal/rack_delegation.rb:  14:in `dispatch'
…/gems/actionpack-3.2.13/lib/action_controller/metal.rb: 246:in `block in action'
…onpack-3.2.13/lib/action_dispatch/routing/route_set.rb:  73:in `call'
…onpack-3.2.13/lib/action_dispatch/routing/route_set.rb:  73:in `dispatch'
…onpack-3.2.13/lib/action_dispatch/routing/route_set.rb:  36:in `call'
…le/ruby/2.0.0/gems/journey-1.0.4/lib/journey/router.rb:  68:in `block in call'
…le/ruby/2.0.0/gems/journey-1.0.4/lib/journey/router.rb:  56:in `each'
…le/ruby/2.0.0/gems/journey-1.0.4/lib/journey/router.rb:  56:in `call'
…onpack-3.2.13/lib/action_dispatch/routing/route_set.rb: 612:in `call'
…b/action_dispatch/middleware/best_standards_support.rb:  17:in `call'
…dor/bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/etag.rb:  23:in `call'
…/ruby/2.0.0/gems/rack-1.4.5/lib/rack/conditionalget.rb:  25:in `call'
…tionpack-3.2.13/lib/action_dispatch/middleware/head.rb:  14:in `call'
…3.2.13/lib/action_dispatch/middleware/params_parser.rb:  21:in `call'
…ionpack-3.2.13/lib/action_dispatch/middleware/flash.rb: 242:in `call'
…/2.0.0/gems/rack-1.4.5/lib/rack/session/abstract/id.rb: 210:in `context'
…/2.0.0/gems/rack-1.4.5/lib/rack/session/abstract/id.rb: 205:in `call'
…npack-3.2.13/lib/action_dispatch/middleware/cookies.rb: 341:in `call'
…s/activerecord-3.2.13/lib/active_record/query_cache.rb:  64:in `call'
…record/connection_adapters/abstract/connection_pool.rb: 479:in `call'
…ack-3.2.13/lib/action_dispatch/middleware/callbacks.rb:  28:in `block in call'
…s/activesupport-3.2.13/lib/active_support/callbacks.rb: 405:in `_run__3040162821033232191__call__4124336814466504234__callbacks'
…s/activesupport-3.2.13/lib/active_support/callbacks.rb: 405:in `__run_callback'
…s/activesupport-3.2.13/lib/active_support/callbacks.rb: 385:in `_run_call_callbacks'
…s/activesupport-3.2.13/lib/active_support/callbacks.rb:  81:in `run_callbacks'
…ack-3.2.13/lib/action_dispatch/middleware/callbacks.rb:  27:in `call'
…ack-3.2.13/lib/action_dispatch/middleware/remote_ip.rb:  31:in `call'
…ndle/ruby/2.0.0/gems/bugsnag-1.3.6/lib/bugsnag/rack.rb:  36:in `call'
….13/lib/action_dispatch/middleware/debug_exceptions.rb:  16:in `call'
…2.13/lib/action_dispatch/middleware/show_exceptions.rb:  56:in `call'
…by/2.0.0/gems/railties-3.2.13/lib/rails/rack/logger.rb:  32:in `call_app'
…by/2.0.0/gems/railties-3.2.13/lib/rails/rack/logger.rb:  16:in `block in call'
…ivesupport-3.2.13/lib/active_support/tagged_logging.rb:  22:in `tagged'
…by/2.0.0/gems/railties-3.2.13/lib/rails/rack/logger.rb:  16:in `call'
…ck-3.2.13/lib/action_dispatch/middleware/request_id.rb:  22:in `call'
…/ruby/2.0.0/gems/rack-1.4.5/lib/rack/methodoverride.rb:  21:in `call'
…/bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/runtime.rb:  17:in `call'
….2.13/lib/active_support/cache/strategy/local_cache.rb:  72:in `call'
…onpack-3.2.13/lib/action_dispatch/middleware/static.rb:  63:in `call'
…by/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb: 136:in `forward'
…by/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb: 245:in `fetch'
…by/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb: 185:in `lookup'
…by/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:  66:in `call!'
…by/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:  51:in `call'
…ruby/2.0.0/gems/rack-timeout-0.0.4/lib/rack/timeout.rb:  16:in `block in call'
       /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/timeout.rb:  65:in `timeout'
…ruby/2.0.0/gems/rack-timeout-0.0.4/lib/rack/timeout.rb:  16:in `call'
…le/ruby/2.0.0/gems/railties-3.2.13/lib/rails/engine.rb: 479:in `call'
…by/2.0.0/gems/railties-3.2.13/lib/rails/application.rb: 223:in `call'
…gems/railties-3.2.13/lib/rails/railtie/configurable.rb:  30:in `method_missing'
…bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/deflater.rb:  13:in `call'
…by/2.0.0/gems/unicorn-4.6.2/lib/unicorn/http_server.rb: 552:in `process_client'
…by/2.0.0/gems/unicorn-4.6.2/lib/unicorn/http_server.rb: 632:in `worker_loop'
…by/2.0.0/gems/unicorn-4.6.2/lib/unicorn/http_server.rb: 500:in `spawn_missing_workers'
…by/2.0.0/gems/unicorn-4.6.2/lib/unicorn/http_server.rb: 511:in `maintain_worker_count'
…by/2.0.0/gems/unicorn-4.6.2/lib/unicorn/http_server.rb: 277:in `join'
/app/vendor/bundle/ruby/2.0.0/gems/unicorn-4.6.2/bin/unicorn:126:in `<top (required)>'
/app/vendor/bundle/ruby/2.0.0/bin/unicorn:23:in `load'
/app/vendor/bundle/ruby/2.0.0/bin/unicorn:23:in `<main>'

Attempts to require "resque/failure/base" when installed alongside "newrelic_rpm" gem

I've found that when running the newrelic_rpm and bugsnag-ruby gems together in the same project, bugsnag will incorrectly detect that Resque is installed because of the Resque instrumentation hooks NewRelic defines.

module Resque
  module Plugins
    module NewRelicInstrumentation
      include NewRelic::Agent::Instrumentation::ControllerInstrumentation

      def around_perform_with_monitoring(*args)
        begin
          perform_action_with_newrelic_trace(:name => 'perform',
                               :class_name => self.name,
                               :category => 'OtherTransaction/ResqueJob') do
            yield(*args)
          end
        ensure
          NewRelic::Agent.shutdown if NewRelic::LanguageSupport.can_fork?
        end
      end
    end
  end
end

I get this error when trying to start a server:

/home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:182:in `require': no such file to load -- resque/failure/base (MissingSourceFile)
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:182:in `require'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:547:in `new_constants_in'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:182:in `require'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/bugsnag-1.2.4/lib/resque/failure/bugsnag.rb:14
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:182:in `require'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:182:in `require'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:547:in `new_constants_in'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/activesupport-2.3.14/lib/active_support/dependencies.rb:182:in `require'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/bugsnag-1.2.4/lib/bugsnag.rb:11
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/bundler-1.1.5/lib/bundler/runtime.rb:68:in `require'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/bundler-1.1.5/lib/bundler/runtime.rb:68:in `require'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/bundler-1.1.5/lib/bundler/runtime.rb:66:in `each'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/bundler-1.1.5/lib/bundler/runtime.rb:66:in `require'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/bundler-1.1.5/lib/bundler/runtime.rb:55:in `each'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/bundler-1.1.5/lib/bundler/runtime.rb:55:in `require'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/bundler-1.1.5/lib/bundler.rb:119:in `require'
    from /vagrant/config/boot.rb:121:in `load_gems'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/rails-2.3.14/lib/initializer.rb:164:in `process'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/rails-2.3.14/lib/initializer.rb:113:in `send'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/rails-2.3.14/lib/initializer.rb:113:in `run'
    from /vagrant/config/environment.rb:13
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/thin-1.4.1/lib/rack/adapter/rails.rb:37:in `require'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/thin-1.4.1/lib/rack/adapter/rails.rb:37:in `load_application'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/thin-1.4.1/lib/rack/adapter/rails.rb:23:in `initialize'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/thin-1.4.1/lib/rack/adapter/loader.rb:45:in `new'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/thin-1.4.1/lib/rack/adapter/loader.rb:45:in `for'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/thin-1.4.1/lib/thin/controllers/controller.rb:169:in `load_adapter'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/thin-1.4.1/lib/thin/controllers/controller.rb:73:in `start'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/thin-1.4.1/lib/thin/runner.rb:185:in `send'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/thin-1.4.1/lib/thin/runner.rb:185:in `run_command'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/thin-1.4.1/lib/thin/runner.rb:151:in `run!'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/lib/ruby/gems/1.8/gems/thin-1.4.1/bin/thin:6
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/bin/thin:19:in `load'
    from /home/vagrant/.rbenv/versions/ree-1.8.7-2012.02/bin/thin:19

Rake integration isn't loaded by default with Rails. Could/should it be?

Hi there

Just found an annoying bug in our app that was occuring while running a rake task. I would have expected errors in rake tasks to be reported, but have just noted in the README that Rake integration needs to be manually added to the Rakefile.

Is there any reason why this integration can't be loaded automatically? Either by a Railtie or some other approach?

Use X-Forwarded-For for user id

At the moment if you're behind a load-balancer the user ids may be wrong.

Unicode issue

I'm having an unicode issue, I was debugging something that somehow involved this object, the fact that it uses Unicode for rate_human makes Bugsnag fail to notify.

{
  id: "jdoe",
  username: "jdoe",
  first_name: "Jane",
  last_name: "Doe",
  rate: 25.00,
  rate_human: "€25.00",     // this might be the issue
  avatar_url: "...",
  registered_at: "2014-03-31T09:36:50.336Z",
  favorited_count: 0,
  profession: "Senior Developer",
  social_urls: {
    twitter: "https://twitter.com/jdoe",
    facebook: "https://facebook.com/jdoe",
    github: "https://github.com/jdoe"
  },
  _links: {
    self: {
      href: "/users/jdoe"
    },
    html: {
      href: "#/u/jdoe"
    },
    favorites: {
      href: "/users/jdoe/favorites"
    },
    add_favorite: {
      method: "post",
      href: "/users/jdoe/favorite"
    }
  }
}

Backtrace:

I, [2014-04-09T12:03:57.122297 #4261]  INFO -- : ** [Bugsnag] Notifying http://notify.bugsnag.com of NameError from api_key e270af4324328a23c41579ecafbbda1c
W, [2014-04-09T12:03:57.405382 #4261]  WARN -- : ** [Bugsnag] Notification to http://notify.bugsnag.com failed, #<Encoding::UndefinedConversionError: "\xE2" from ASCII-8BIT to UTF-8>
W, [2014-04-09T12:03:57.405986 #4261]  WARN -- : ** [Bugsnag] ["/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/core_ext/object/json.rb:34:in `encode'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/core_ext/object/json.rb:34:in `to_json'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/core_ext/object/json.rb:34:in `to_json_with_active_support_encoder'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/json/encoding.rb:56:in `to_json'", "/usr/local/rbenv/versions/2.1.1/lib/ruby/2.1.0/json/common.rb:223:in `generate'", "/usr/local/rbenv/versions/2.1.1/lib/ruby/2.1.0/json/common.rb:223:in `generate'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/json/encoding.rb:96:in `stringify'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/json/encoding.rb:34:in `encode'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/json/encoding.rb:21:in `encode'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/core_ext/object/json.rb:37:in `to_json_with_active_support_encoder'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/multi_json-1.9.2/lib/multi_json/adapters/json_common.rb:21:in `dump'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/multi_json-1.9.2/lib/multi_json/adapter.rb:24:in `dump'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/multi_json-1.9.2/lib/multi_json.rb:138:in `dump'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/helpers.rb:85:in `dump_json'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/notification.rb:31:in `deliver_exception_payload'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/notification.rb:224:in `block in deliver'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/middleware_stack.rb:59:in `block in run'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/middleware/callbacks.rb:12:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/middleware/callbacks.rb:12:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/middleware/warden_user.rb:36:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/middleware/rails3_request.rb:29:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/middleware/rack_request.rb:47:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/middleware_stack.rb:64:in `run'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/notification.rb:173:in `deliver'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag.rb:45:in `notify'", "/data/apps/secret/releases/20140409115113/app/api/exception_handlers.rb:24:in `block (2 levels) in <module:ExceptionHandlers>'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/grape-0.6.1/lib/grape/middleware/error.rb:49:in `instance_exec'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/grape-0.6.1/lib/grape/middleware/error.rb:49:in `exec_handler'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/grape-0.6.1/lib/grape/middleware/error.rb:37:in `rescue in call!'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/grape-0.6.1/lib/grape/middleware/error.rb:24:in `call!'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/grape-0.6.1/lib/grape/middleware/base.rb:18:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/newrelic-grape-1.3.1/lib/newrelic-grape/instrument.rb:19:in `block in call!'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/newrelic_rpm-3.7.2.192/lib/new_relic/agent/instrumentation/controller_instrumentation.rb:339:in `perform_action_with_newrelic_trace'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/newrelic-grape-1.3.1/lib/newrelic-grape/instrument.rb:18:in `call!'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/grape-0.6.1/lib/grape/middleware/base.rb:18:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/head.rb:11:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:138:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/grape-0.6.1/lib/grape/endpoint.rb:155:in `call!'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/grape-0.6.1/lib/grape/endpoint.rb:145:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-mount-0.8.3/lib/rack/mount/route_set.rb:152:in `block in call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-mount-0.8.3/lib/rack/mount/code_generation.rb:96:in `block in recognize'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-mount-0.8.3/lib/rack/mount/code_generation.rb:68:in `optimized_each'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-mount-0.8.3/lib/rack/mount/code_generation.rb:95:in `recognize'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-mount-0.8.3/lib/rack/mount/route_set.rb:141:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/grape-0.6.1/lib/grape/api.rb:525:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/grape-0.6.1/lib/grape/api.rb:42:in `call!'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/grape-0.6.1/lib/grape/api.rb:38:in `call'", "/data/apps/secret/releases/20140409115113/app/api/logging.rb:21:in `block in call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/notifications.rb:161:in `instrument'", "/data/apps/secret/releases/20140409115113/app/api/logging.rb:20:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:138:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/actionpack-4.1.0.rc2/lib/action_dispatch/journey/router.rb:71:in `block in call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/actionpack-4.1.0.rc2/lib/action_dispatch/journey/router.rb:59:in `each'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/actionpack-4.1.0.rc2/lib/action_dispatch/journey/router.rb:59:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/actionpack-4.1.0.rc2/lib/action_dispatch/routing/route_set.rb:676:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/newrelic_rpm-3.7.2.192/lib/new_relic/rack/error_collector.rb:55:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/newrelic_rpm-3.7.2.192/lib/new_relic/rack/agent_hooks.rb:32:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/newrelic_rpm-3.7.2.192/lib/new_relic/rack/browser_monitoring.rb:27:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/newrelic_rpm-3.7.2.192/lib/new_relic/rack/developer_mode.rb:45:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-cors-0.2.9/lib/rack/cors.rb:54:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/warden-1.2.3/lib/warden/manager.rb:35:in `block in call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/warden-1.2.3/lib/warden/manager.rb:34:in `catch'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/warden-1.2.3/lib/warden/manager.rb:34:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/etag.rb:23:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/conditionalget.rb:35:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/head.rb:11:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/actionpack-4.1.0.rc2/lib/action_dispatch/middleware/params_parser.rb:27:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/actionpack-4.1.0.rc2/lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/callbacks.rb:82:in `run_callbacks'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/actionpack-4.1.0.rc2/lib/action_dispatch/middleware/callbacks.rb:27:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/actionpack-4.1.0.rc2/lib/action_dispatch/middleware/remote_ip.rb:76:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/bundler/gems/bugsnag-ruby-3476fe25d0d1/lib/bugsnag/rack.rb:42:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/actionpack-4.1.0.rc2/lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/actionpack-4.1.0.rc2/lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/railties-4.1.0.rc2/lib/rails/rack/logger.rb:38:in `call_app'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/railties-4.1.0.rc2/lib/rails/rack/logger.rb:20:in `block in call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/tagged_logging.rb:68:in `block in tagged'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/tagged_logging.rb:26:in `tagged'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/tagged_logging.rb:68:in `tagged'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/railties-4.1.0.rc2/lib/rails/rack/logger.rb:20:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/actionpack-4.1.0.rc2/lib/action_dispatch/middleware/request_id.rb:21:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/runtime.rb:17:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/activesupport-4.1.0.rc2/lib/active_support/cache/strategy/local_cache_middleware.rb:26:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/railties-4.1.0.rc2/lib/rails/engine.rb:515:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/railties-4.1.0.rc2/lib/rails/application.rb:142:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/railties-4.1.0.rc2/lib/rails/railtie.rb:194:in `public_send'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/railties-4.1.0.rc2/lib/rails/railtie.rb:194:in `method_missing'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/puma-2.7.1/lib/puma/configuration.rb:68:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/puma-2.7.1/lib/puma/server.rb:486:in `handle_request'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/puma-2.7.1/lib/puma/server.rb:357:in `process_client'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/puma-2.7.1/lib/puma/server.rb:250:in `block in run'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/puma-2.7.1/lib/puma/thread_pool.rb:92:in `call'", "/data/apps/secret/shared/bundle/ruby/2.1.0/gems/puma-2.7.1/lib/puma/thread_pool.rb:92:in `block in spawn_thread'"]

SystemExit when sidekiq restarted

We are seeing SystemExit error pretty much when we restarted our sidekiq. We didn't see it before with our previous exception vendor. What is this about? Here's the stacktrace:

SystemExitvendor/bundle/ruby/1.9.1/gems/sidekiq-2.17.0/lib/sidekiq/cli.rb:82
exit

vendor/bundle/ruby/1.9.1/gems/sidekiq-2.17.0/lib/sidekiq/cli.rb:82:in exit
from vendor/bundle/ruby/1.9.1/gems/sidekiq-2.17.0/lib/sidekiq/cli.rb:82:in rescue in run
from vendor/bundle/ruby/1.9.1/gems/sidekiq-2.17.0/lib/sidekiq/cli.rb:66:in run
from vendor/bundle/ruby/1.9.1/gems/sidekiq-2.17.0/bin/sidekiq:8:in <top (required)>
from vendor/bundle/ruby/1.9.1/bin/sidekiq:23:in load
from vendor/bundle/ruby/1.9.1/bin/sidekiq:23:in

Release new gem version

for the fix in 64a5f8c

Shortcut to append custom data to Bugsnag.notify

I assumed that, outside controllers, I can write:

Bugsnag.notify(exception, { :project_id => 1 })

but what I actually need to write is:

Bugsnag.notify(exception, { :meta_data => { :custom => { :project_id => 1 } } } )

Can you provide a shortcut in the API?

parameter filtering is inconsistent with rails

We observe that bugsnag is filtering parameters with semantics completely different from those used by rails. For instance, our rails application is configured to filter out the parameter "q", which in rails is an exact match, while bugsnag filters all strings including the character "q" (think action_dispatch.request.*).

Here's the responsible line in the bugsnag railitie: https://github.com/bugsnag/bugsnag-ruby/blob/master/lib/bugsnag/railtie.rb#L2

And Rails' ParameterFilter: https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/http/parameter_filter.rb

Truncation appends [TRUNCATED] even if the field is not truncated

The bug is caused by this.

Middleware not being executed when exceptions occur in Sidekiq

I've created a middleware which is working correctly in Rails 4.x, but it's not being run when an exception occurs in Sidekiq.

Bugsnag 2.0.2.

Add to your Reference page about ensuring that set :raise_errors, true for us Sinatra users

Bugsnag is sending errors when running in "development" environment?

Is that a bug or by design?

Caused exceptions being sent in the wrong order?

In some cases (e.g. Active Model rollback) exceptions are being shown as "A caused B" when B appears to have happened before A.

Bugsnag.notify_or_ignore return value

Coming from Airbrake, notify_or_ignore used to return the notification (as long as it wasn't ignored). Would you be open to changing bugsnag to operate the same way?

Environment tab should be optionally sent

We should only send the rack env tab optionally, default off. Many users have mentioned that they wish stuff wasnt automatically transmitted and it is of limited use to most customers.

JRuby stacktrace will cause Bugsnag not to report error

I currently use bugsnag in a JRuby environment and I ran into the following problem.

All "pure Ruby errors" are handled fine. But from time to time, there is an error that goes into Java specific code (in my case sequel together with a JDBC connection).

The stacktrace then looks like this:

"com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(com/microsoft/sqlserver/jdbc/SQLServerException.java:190)"
"com.microsoft.sqlserver.jdbc.SQLServerException.ConvertConnectExceptionToSQLServerException(com/microsoft/sqlserver/jdbc/SQLServerException.java:241)"
"com.microsoft.sqlserver.jdbc.SocketFinder.findSocket(com/microsoft/sqlserver/jdbc/IOBuffer.java:2243)"
"com.microsoft.sqlserver.jdbc.TDSChannel.open(com/microsoft/sqlserver/jdbc/IOBuffer.java:491)"
"com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(com/microsoft/sqlserver/jdbc/SQLServerConnection.java:1309)"
"com.microsoft.sqlserver.jdbc.SQLServerConnection.login(com/microsoft/sqlserver/jdbc/SQLServerConnection.java:991)"
"com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(com/microsoft/sqlserver/jdbc/SQLServerConnection.java:827)"
"com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(com/microsoft/sqlserver/jdbc/SQLServerDriver.java:1012)"
"java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:606)"
"RUBY.connect(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/adapters/jdbc.rb:252)"
"RUBY.make_new(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/connection_pool.rb:96)"
"RUBY.make_new(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:158)"
"RUBY.available(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:137)"
"RUBY.acquire(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:127)"
"RUBY.sync(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:194)"
"org.jruby.ext.thread.Mutex.synchronize(org/jruby/ext/thread/Mutex.java:149)"
"RUBY.sync(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:194)"
"RUBY.acquire(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:126)"
"RUBY.hold(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/connection_pool/threaded.rb:94)"
"RUBY.synchronize(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/database/connecting.rb:234)"
"RUBY.server_version(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/adapters/shared/mssql.rb:162)"
"RUBY.server_version(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/adapters/shared/mssql.rb:675)"
"RUBY.is_2012_or_later?(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/adapters/shared/mssql.rb:771)"
"RUBY.select_limit_sql(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/adapters/shared/mssql.rb:893)"
"RUBY.clause_sql(/Users/leifg/.rbenv/versions/jruby-1.7.11/lib/ruby/gems/shared/gems/sequel-4.9.0/lib/sequel/dataset/sql.rb:834)"
"org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613)"

so the regular expression used for extracting the file, method and line returns nil. so the stacktrace will be empty

I'm not sure if the "RUBY" is prepended by Sequel or JRuby.

However the much more severe part is: The notification is sent to the server but never shows up on the dashboard. Meaning, no notifications will be triggered and the error goes unnoticed.

Params_filters badly named

We should update the docs to make it clear that params filters filter the metadata, and also symlink a method with a more appropriate name than params_filters.

Calling bugsnag:deploy from a rake task

We use a rake task to wrap our Heroku deployment, so I'm looking at adding Bugsnag deployment tracking to it. I've tried a few different methods, but I always get the same error.

WARN -- : ** [Bugsnag] No API key configured, couldn't notify

ENV['BUGSNAG_RELEASE_STAGE'] = to
ENV['BUGSNAG_REVISION'] = current_revision
ENV['BUGSNAG_BRANCH'] = current_branch
ENV['BUGSNAG_API_KEY'] = 'my_api_key_here'
Rake::Task["bugsnag:deploy"].invoke

environment = {
  'BUGSNAG_RELEASE_STAGE' => to,
  'BUGSNAG_REVISION' => current_revision,
  'BUGSNAG_BRANCH' => current_branch,
  'BUGSNAG_API_KEY' => 'my_api_key_here',
}
system(environment, 'rake bugsnag:deploy')

I've also tried putting the BUGSNAG_API_KEY directly into the system command line. None of this works, though manually executing bugsnag:deploy from the command line does work.

Using Ruby 2.1.2, it seems like more of an issue with Ruby or something weird with our setup then with Bugsnag. But maybe there could be a better way to pass this data through to the rake task?

Figure out occasional failure on jruby-1.8mode

https://travis-ci.org/bugsnag/bugsnag-ruby/jobs/30413022

Sometimes it fails, sometimes not.

@loopj believes it's a Travis issue.

Before bugsnag notify should allow you not to send

You should be able to ignore a notification from within a middleware or a before bugsnag notify, and I dont think you can right now.

Version 1.6.3 sends notification in test/development environment

I noticed that, after upgrading from 1.5.x, bugsnag started to report errors in development.

I believe the issue is associated with 501e456

In fact, in the Rails plugin, the notify_release_stages is never set and it falls into the nil case.

Bugsnag.configure do |config|
  config.logger ||= rails_logger
  config.release_stage = RAILS_ENV if defined?(RAILS_ENV)
  config.project_root = RAILS_ROOT if defined?(RAILS_ROOT)

  ...
end

I assume it should set to ["production"] by default. Do you agree?

If you agree, I'll submit a patch.

Add regex support to `config.params_filters`

To solve the problem seen in #137, we should enhance config.params_filters to support regular expressions.

• Consider backwards compatibility. We need to preserve the current "string contains" behaviour.
• Import string params filters from rails by converting them to "exact match" regexes
• Import regex params filters from rails untouched
• Update the docs to describe the new regex behavior

Unable to display UploadedFile

When a multi-part POST includes a file, the Rails logger's error report includes a UploadedFile with a @tempfile. However Bugsnag reports a null tempfile.

That can be a little misleading.

Rails logger:

Parameters: {"Message-Id"=>"<[e-mail]>", 
"attachment-1"=>#<ActionDispatch::Http::UploadedFile:0x007fe2a68ce200 @original_filename="attachment-1", 
@content_type="application/octet-stream", @headers="Content-Disposition: form-data; name=\"attachment-1\"; 
filename=\"attachment-1\"\r\nContent-Type: application/octet-stream\r\n", 
@tempfile=#<Tempfile:/var/folders/0l/4rylf65j1_s73dyz_1bfmmg80000gn/T/RackMultipart20140201-70466-wp8678>>, 
"signature"=>"b8475e7de85932f7182a991610e9312006920e5f06c367c69930e8374be30a0f", "timestamp"=>"1390893171", 
"token"=>"6pl-6b98xxx6l15-skxa20sebm3-v56q3lx19qkmocuzxhiwx6"}

vs Bugsnag:

No implicit conversion of nil into Hash

I've been seeing this error every few minutes on our production app - any ideas how to debug:

2014-06-25T18:03:29.594704+00:00 app[web.11]: App 141 stdout: ** [Bugsnag] Bugsnag middleware error: no implicit conversion of nil into Hash
2014-06-25T18:03:29.594707+00:00 app[web.11]: App 141 stdout: ** [Bugsnag] Middleware error stacktrace: ["/app/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/request.rb:225:in `merge'", "/app/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/request.rb:225:in `params'", "/app/vendor/bundle/ruby/2.1.0/gems/bugsnag-2.0.3/lib/bugsnag/middleware/rack_request.rb:12:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/bugsnag-2.0.3/lib/bugsnag/middleware_stack.rb:64:in `run'", "/app/vendor/bundle/ruby/2.1.0/gems/bugsnag-2.0.3/lib/bugsnag/notification.rb:200:in `deliver'", "/app/vendor/bundle/ruby/2.1.0/gems/bugsnag-2.0.3/lib/bugsnag.rb:54:in `notify_or_ignore'", "/app/vendor/bundle/ruby/2.1.0/gems/bugsnag-2.0.3/lib/bugsnag.rb:67:in `auto_notify'", "/app/vendor/bundle/ruby/2.1.0/gems/bugsnag-2.0.3/lib/bugsnag/rack.rb:39:in `rescue in call'", "/app/vendor/bundle/ruby/2.1.0/gems/bugsnag-2.0.3/lib/bugsnag/rack.rb:35:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/lograge-0.3.0/lib/lograge/rails_ext/rack/logger.rb:15:in `call_app'", "/app/vendor/bundle/ruby/2.1.0/gems/railties-4.1.1/lib/rails/rack/logger.rb:20:in `block in call'", "/app/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.1/lib/active_support/tagged_logging.rb:68:in `block in tagged'", "/app/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.1/lib/active_support/tagged_logging.rb:26:in `tagged'", "/app/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.1/lib/active_support/tagged_logging.rb:68:in `tagged'", "/app/vendor/bundle/ruby/2.1.0/gems/railties-4.1.1/lib/rails/rack/logger.rb:20:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/middleware/request_id.rb:21:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/methodoverride.rb:21:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/runtime.rb:17:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_dispatch/middleware/static.rb:64:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/sendfile.rb:112:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/librato-rack-0.4.5/lib/librato/rack.rb:94:in `process_request'", "/app/vendor/bundle/ruby/2.1.0/gems/librato-rack-0.4.5/lib/librato/rack.rb:64:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/railties-4.1.1/lib/rails/engine.rb:514:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/railties-4.1.1/lib/rails/application.rb:144:in `call'", "/app/vendor/bundle/ruby/2.1.0/gems/passenger-4.0.45/lib/phusion_passenger/rack/thread_handler_extension.rb:74:in `process_request'", "/app/vendor/bundle/ruby/2.1.0/gems/passenger-4.0.45/lib/phusion_passenger/request_handler/thread_handler.rb:141:in `accept_and_process_next_request'", "/app/vendor/bundle/ruby/2.1.0/gems/passenger-4.0.45/lib/phusion_passenger/request_handler/thread_handler.rb:109:in `main_loop'", "/app/vendor/bundle/ruby/2.1.0/gems/passenger-4.0.45/lib/phusion_passenger/request_handler.rb:448:in `block (3 levels) in start_threads'"]
2014-06-25T18:03:29.594846+00:00 app[web.11]: App 141 stdout:   vendor/bundle/ruby/2.1.0/gems/newrelic_rpm-3.8.1.221/lib/new_relic/rack/error_collector.rb:55:in `call'

capistrano3 support doesn't use rake correctly.

See discussion 169ca0e#commitcomment-5800387

Gem broken after 1.8.5 for Delayed::Job 2.x users?

See my comment on the commit that introduced the DJ support.

Delayed::Plugin didn't exist in Delayed::Job 2.1.x.

Maybe the implied dependency on Delayed::Job 3.x+ should be declared somewhere in the CHANGELOG & README. Not a huge deal considering only pretty damn old version of DJs would be affected.

rails.request.exceptions also reports intended

Missing info on exception

Most of the time we only see the stacktrace tab on our exceptions now.
Using version 1.2.4 of Bugsnag. Rails 2.3.

Consider ignoring interruptions

I Ctrl-c'ed on WEBrick and presumably that action led to sending information about the interruption. The information attached to this exception is pretty useless.

bugsnag/sidekiq: notify_or_ignore ?

Why the ignore_classes option is not taken into count in sidekiq integration?
https://github.com/bugsnag/bugsnag-ruby/blob/master/lib/bugsnag/sidekiq.rb#L7

Is there a way to ignore some exceptions occurred in sidekiq job?

Using multiple API keys in the same application is hard

Currently there is a global Configuration object which makes it hard to post exceptions to a second project.
We have a use-case where we are proxying exceptions from our customers and want to shuffle those to a different place separate from our rails errors.

undefined method record_task_metadata

Hi

I get this when running some Rake tasks (e.g. asset precomile):

undefined method `record_task_metadata=' for Rake::TaskManager:Module

Ive tried adding the code in the README around "require 'bugsnag/rake'". Doesn't work

Thanks!

A Rake Task Failed with Bugsnag Rake Integration

I tried the rake integration and it works well except sunspot gem. When I tried rake sunspot:reindex it ended up with the error "undefined method `with_defaults' for nil:NilClass". I used bugsnag 1.4.2 and sunspot 2.0.0.
Could you solve this issue?

Method to wrap code to notify about

Since this is a very common pattern in my code, for actions that can generate errors but are not critical:

begin
  do_something
rescue => e
  Bugsnag.notify(e)
end

I created this extension to Bugsnag that would be nice if you could just include it:

module Bugsnag
  class << self
    def notifying(overrides=nil, request_data=nil)
      yield
    rescue => e
      notify(e, overrides, request_data)
    end
  end
end

so the previous code ends up being:

Bugsnag.notifying do
  do_something
end

Isn't Ruby great?

Capistrano deployment notification for non rails apps

We deploy a non-rails app with Capistrano and hence would love to have the deployment notification send to bugsnag. However after adding require "bugsnag/capistrano" to our config/deploy.rb we get a #<NameError: uninitialized constant Rails> and the notification fails.

  * …
  * 2014-03-18 15:35:22 15:35:22 == Currently executing `bugsnag:deploy'
  * executing "cat /foo/bar/current/REVISION"
    servers: ["example.com"]
    [example.com] executing command
    command finished in 881ms
  * executing "cd '/foo/bar/current' && RAILS_ENV=production bundle exec rake bugsnag:deploy BUGSNAG_RELEASE_STAGE=production BUGSNAG_REVISION=1234 [email protected]:beep/boop.git BUGSNAG_BRANCH=master"
    servers: ["example.com"]
    [exmaple.com] executing command
 ** [out :: exmaple.com] cane not available, quality task not provided.
 ** [out :: exmaple.com] W, [2014-03-18T23:35:25.594850 #7403]  WARN -- : ** [Bugsnag] Deploy notification failed, #<NameError: uninitialized constant Rails>
    command finished in 1677ms
 ** Bugsnag deploy notification complete.

Rake integration sets context to environment

httparty is awful

Depending on httparty produces obnoxious output in bundle install for all apps that add bugnag to their Gemfile. See: jnunemaker/httparty#321

Your bundle is complete!
Use `bundle show [gemname]` to see where a bundled gem is installed.
Post-install message from httparty:
When you HTTParty, you must party hard!

Would you consider a pull-request to replace httparty with plain Net::HTTP or a grown-up library like Faraday?

Load order issue when using resque/sidekiq/mailmain integration

At the moment the integrations only work properly if the gemfile is ordered correctly. We should fix this.

Drop Ruby 1.8 support

It's about time. #justsaying.
Weird errors in Travis. (See: #86).
Besides, rake which your project depends on, it's no longer running on 1.8, so you either have to specify an older version, or well, do what the title suggests.

Capistrano 3 support

We call info on a local task that seems to not be defined. Perhaps we should use puts in both cases.

Remove HTTParty dependency

The bugsnag gem has a dependency on the HTTParty gem, and appears to only use this in one place. This could be removed by adding 10-20 lines of code and making minor external changes, like error messages not being identical. Would you accept a patch that removed the HTTParty dependency?

On a related topic, I looked in your API docs and it does not appear that there is a test server for use during API integrations. Is something like that available?

Rails 4 sessions appear in custom tab

no notification when notify_release_stages set in Sinatra app

With my Sinatra app running in a staging environment, I am generating a bugsnag notification using Bugsnag.notify. When notify_release_stages is set to ["staging"], the error does not show up in the project's dashboard, even though I've confirmed that release_stage is indeed set to "staging". If I comment out notify_release_stages in my bugsnag config file, the error successfully appears in the dashboard.

Allow to notify about sidekiq error only after several insuccessful retries

We are sending emails with sidekiq workers that are monitored for exceptions by bugsnag.

There are a lot of one time exceptions like IO::EAGAINWaitReadable.
The 5 seconds downtime of the mail server (e.g it is redeployed) results in hundreds of such errors.

Can we setup bugsnag-sidekiq to notify about exceptions only after several unsuccessful retries?