honeybadger-io / honeybadger-ruby Goto Github PK

View Code? Open in Web Editor NEW

230.0 11.0 142.0 2.81 MB

Ruby gem for reporting errors to honeybadger.io

Home Page: https://docs.honeybadger.io/lib/ruby/

License: MIT License

Ruby 99.16% HTML 0.84%

honeybadger ruby rails cli-command error-notification

honeybadger-ruby's Introduction

Honeybadger for Ruby

This is the notifier gem for integrating apps with the ⚡ Honeybadger Exception Notifier for Ruby and Rails.

When an uncaught exception occurs, Honeybadger will POST the relevant data to the Honeybadger server specified in your environment.

Documentation and Support

For comprehensive documentation and support, check out our documentation site.

Changelog

Changelog is generated automatically as part of the release process, using conventional commits.

Development

Pull requests are welcome. If you're adding a new feature, please submit an issue as a preliminary step; that way you can be (moderately) sure that your pull request will be accepted.

If you're integrating your gem/open source project with Honeybadger, please consider submitting an official plugin to our gem. Submit an issue to discuss with us!

We use YARD to document our API. Classes and methods which are safe to depend on in your gems/projects are marked "Public". All other classes/methods are considered internal and may change without notice -- don't depend on them! If you need a new public API, we're happy to work with you. Submit an issue to discuss.

To contribute your code:

Fork it.
Create a topic branch git checkout -b my_branch
Make your changes and add an entry to the CHANGELOG.
Commit your changes git commit -am "Boom"
Push to your branch git push origin my_branch
Send a pull request

Running the tests

We're using the Appraisal gem to run our RSpec test suite against multiple versions of Rails.

The unit test suite can be run with rake spec:units.
The integration test suite can be run with rake spec:features.
The combined suite can be run with rake.

Releasing

Releases are automated, using Github Actions:

When a PR is merged on master, the ruby.yml workflow is executed, which runs the tests.
If the tests pass, the release.yml workflow will be executed.
Depending on the commit message, a release PR will be created with the suggested the version bump and changelog. Note: Not all commit messages trigger a new release, for example, chore: ... will not trigger a release.
If the release PR is merged, the release.yml workflow will be executed again, and this time it will create a github release, bundle the gem and push it to RubyGems.

License

The Honeybadger gem is MIT licensed. See the LICENSE file in this repository for details.

honeybadger-ruby's People

Contributors

Stargazers

Watchers

Forkers

localshred jacquescrocker indirect pdswan dplummer cheerful digitaltoad evilfaeton mwean aprexis asharma-ror benubois gevans monde raykrueger mogotest phstc shadowban oneamtu fatsoma vipulnsward futurelearn jmazzi brainopia stympy murraysum derrickreimer realdigitalmedia rramsden kensodev schoolstatus luvtechno jainankush12 stamm cdale77 voanhduy1512 joeygo23 workable kylerippey cgunther dmitry alexeyfrank tassosl conraddecker nexiahome-orig tskogberg davegw aharpervc flushentitypacket rhodrid questionmarc malept chloeandisabel jonleighton terence2014 ivanvc ccollins joshado saikrishnagaddipati taf2 quixoten degica starrhorne bartes gametimesf cgamesplay on-site bradfrost1 silasjmatson nehachopra justinaiken gherry invoca minhajuddin kienlevan gabelerner aselder michaelherold zinkkrysty natesholland nessamurmur nicolasleger pythonandchips reachnetwork brianstien krim mstruve jjcarstens rubemz simplyinsured struve tongueroo szymzet fernandes bwsewell nahiluhmot iftheshoefritz ye-man pcreux bajena

honeybadger-ruby's Issues

Honeybadger doesn't filter params for context info...

When calling Honeybadger.context(...), we noticed hash elements slipping in that we placed in our params_filters showing up in honeybadger notifications. Would it make sense to filter these like the rest in https://github.com/honeybadger-io/honeybadger-ruby/blob/master/lib/honeybadger/notice.rb#L286

we made a quick monkeypatch to accomplish what we wanted, but there may be a more appropriate location to insert this logic (in Honeybadger::Notice for example (see the reference above))

module Honeybadger
  # modify context data to filter based on the above params_filters opts
  def self.context(hash = {})
    hash = hash.clone
    config = Honeybadger.configuration.merge(:exception => RuntimeError.new)
    Honeybadger::Notice.new(config).send(:filter, hash)
    Thread.current[:honeybadger_context] ||= {}
    Thread.current[:honeybadger_context].merge!(hash)
    self
  end
end

NoMethodError: undefined method `[]' for nil:NilClass in Rails 3.2 project

When I run the generator on a Rails 3.2 project I get the following exception. Rather than the expected test exception this shows up in my account in it's place. Otherwise, everything seems to be working fine.

NoMethodError: undefined method `[]' for nil:NilClass
    [GEM_ROOT]/gems/actionpack-3.2.15/lib/action_dispatch/middleware/debug_exceptions.rb:18:in `call`
    [GEM_ROOT]/gems/actionpack-3.2.15/lib/action_dispatch/middleware/show_exceptions.rb:56:in `call`
    [GEM_ROOT]/gems/railties-3.2.15/lib/rails/rack/logger.rb:32:in `call_app`
    [GEM_ROOT]/gems/railties-3.2.15/lib/rails/rack/logger.rb:16:in `block in call`
    [GEM_ROOT]/gems/activesupport-3.2.15/lib/active_support/tagged_logging.rb:22:in `tagged`
    [GEM_ROOT]/gems/railties-3.2.15/lib/rails/rack/logger.rb:16:in `call`
    [GEM_ROOT]/gems/quiet_assets-1.0.2/lib/quiet_assets.rb:18:in `call_with_quiet_assets`
    [GEM_ROOT]/gems/actionpack-3.2.15/lib/action_dispatch/middleware/request_id.rb:22:in `call`
    [GEM_ROOT]/gems/rack-1.4.5/lib/rack/methodoverride.rb:21:in `call`
    [GEM_ROOT]/gems/rack-1.4.5/lib/rack/runtime.rb:17:in `call`
    [GEM_ROOT]/gems/activesupport-3.2.15/lib/active_support/cache/strategy/local_cache.rb:72:in `call`
    [GEM_ROOT]/gems/rack-1.4.5/lib/rack/lock.rb:15:in `call`
    [GEM_ROOT]/gems/actionpack-3.2.15/lib/action_dispatch/middleware/static.rb:63:in `call`
    [GEM_ROOT]/gems/rack-mini-profiler-0.1.31/Ruby/lib/mini_profiler/profiler.rb:278:in `call`
    [GEM_ROOT]/gems/railties-3.2.15/lib/rails/engine.rb:484:in `call`
    [GEM_ROOT]/gems/railties-3.2.15/lib/rails/application.rb:231:in `call`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/task.rb:236:in `call`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/task.rb:236:in `block in execute`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/task.rb:231:in `each`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/task.rb:231:in `execute`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/task.rb:175:in `block in invoke_with_call_chain`
    /home/fletch/.rvm/rubies/ruby-1.9.3-p484/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/task.rb:168:in `invoke_with_call_chain`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/task.rb:161:in `invoke`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/application.rb:149:in `invoke_task`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/application.rb:106:in `block (2 levels) in top_level`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/application.rb:106:in `each`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/application.rb:106:in `block in top_level`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/application.rb:115:in `run_with_threads`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/application.rb:100:in `top_level`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/application.rb:78:in `block in run`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/application.rb:165:in `standard_exception_handling`
    [GEM_ROOT]/gems/rake-10.1.0/lib/rake/application.rb:75:in `run`
    [GEM_ROOT]/gems/rake-10.1.0/bin/rake:33:in `<top (required)>`
    [GEM_ROOT]/bin/rake:19:in `load`
    [GEM_ROOT]/bin/rake:19:in `<main>`
    [GEM_ROOT]/bin/ruby_executable_hooks:15:in `eval`
    [GEM_ROOT]/bin/ruby_executable_hooks:15:in `<main>`

RuntimeError: can't add a new key into hash during iteration

❯ ruby -v      
jruby 1.7.5 (1.9.3p392) 2013-10-07 74e9291 on OpenJDK Server VM 1.7.0_51-b00 [linux-i386]

❯ rails -v
Rails 3.2.13

RuntimeError - can't add a new key into hash during iteration:
  org/jruby/RubyHash.java:971:in `[]='
  honeybadger (1.10.2) lib/honeybadger/monitor/worker.rb:62:in `add_metric'
  honeybadger (1.10.2) lib/honeybadger/monitor/worker.rb:22:in `timing'
  honeybadger (1.10.2) lib/honeybadger/monitor/railtie.rb:17:in `Railtie'
  org/jruby/RubyProc.java:271:in `call'
  activesupport (3.2.13) lib/active_support/notifications/fanout.rb:47:in `publish'
  activesupport (3.2.13) lib/active_support/notifications/fanout.rb:25:in `publish'
  org/jruby/RubyArray.java:1613:in `each'
  activesupport (3.2.13) lib/active_support/notifications/fanout.rb:25:in `publish'
  activesupport (3.2.13) lib/active_support/notifications/instrumenter.rb:25:in `instrument'
  activesupport (3.2.13) lib/active_support/notifications.rb:123:in `instrument'
  actionpack (3.2.13) lib/action_controller/metal/instrumentation.rb:29:in `process_action'
  actionpack (3.2.13) lib/action_controller/metal/params_wrapper.rb:207:in `process_action'
  activerecord (3.2.13) lib/active_record/railties/controller_runtime.rb:18:in `process_action'
  actionpack (3.2.13) lib/abstract_controller/base.rb:121:in `process'
  actionpack (3.2.13) lib/abstract_controller/rendering.rb:45:in `process'
  actionpack (3.2.13) lib/action_controller/metal.rb:203:in `dispatch'
  actionpack (3.2.13) lib/action_controller/metal/rack_delegation.rb:14:in `dispatch'
  actionpack (3.2.13) lib/action_controller/metal.rb:246:in `action'
  org/jruby/RubyProc.java:271:in `call'
  actionpack (3.2.13) lib/action_dispatch/routing/route_set.rb:73:in `dispatch'
  actionpack (3.2.13) lib/action_dispatch/routing/route_set.rb:36:in `call'
  journey (1.0.4) lib/journey/router.rb:68:in `call'
  org/jruby/RubyArray.java:1613:in `each'
  journey (1.0.4) lib/journey/router.rb:56:in `call'
  actionpack (3.2.13) lib/action_dispatch/routing/route_set.rb:612:in `call'
  warden (1.2.3) lib/warden/manager.rb:35:in `call'
  org/jruby/RubyKernel.java:1282:in `catch'
  warden (1.2.3) lib/warden/manager.rb:34:in `call'
  actionpack (3.2.13) lib/action_dispatch/middleware/best_standards_support.rb:17:in `call'
  rack (1.4.5) lib/rack/etag.rb:23:in `call'
  rack (1.4.5) lib/rack/conditionalget.rb:25:in `call'
  actionpack (3.2.13) lib/action_dispatch/middleware/head.rb:14:in `call'
  actionpack (3.2.13) lib/action_dispatch/middleware/params_parser.rb:21:in `call'
  actionpack (3.2.13) lib/action_dispatch/middleware/flash.rb:242:in `call'

Compatibility issue with Capistrano 3.0

When I run cap deploy I receive this error:

cap aborted!
undefined method `instance' for Capistrano::Configuration:Class
/usr/local/rvm/gems/ruby-2.0.0-p247/bundler/gems/honeybadger-ruby-d24295845fcf/lib/honeybadger/capistrano.rb:46:in `<top (required)>'
/Users/imouaddine/Developer/rails/neptune/Capfile:10:in `require'
/Users/imouaddine/Developer/rails/neptune/Capfile:10:in `<top (required)>'
/usr/local/rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/application.rb:22:in `load_rakefile'
/usr/local/rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/application.rb:12:in `run'
/usr/local/rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/bin/cap:3:in `<top (required)>'
/usr/local/rvm/gems/ruby-2.0.0-p247/bin/cap:23:in `load'
/usr/local/rvm/gems/ruby-2.0.0-p247/bin/cap:23:in `<main>'
/usr/local/rvm/gems/ruby-2.0.0-p247/bin/ruby_noexec_wrapper:14:in `eval'
/usr/local/rvm/gems/ruby-2.0.0-p247/bin/ruby_noexec_wrapper:14:in `<main>'
(See full trace by running task with --trace)

I'm using Capistrano 3, here is a snippet from my Gemfile:

gem 'honeybadger'
group :development do
  gem 'capistrano', "~> 3.0.0"
  gem 'capistrano-bundler'
  gem 'capistrano-rails'
  gem 'capistrano-rvm'
end

And in my Capfile, I have this:

require 'honeybadger/capistrano'

Thanks for looking at the issue.

Controller notify_honeybadger should be protected

The comment on the method says that you can call this method to manually report an exception with appropriate context. (Line 17 of https://github.com/honeybadger-io/honeybadger-ruby/blob/master/lib/honeybadger/rails/controller_methods.rb)

However, because the method is private, I am not able to call it. Instead, an exception is thrown. I would like to call this method in my API controllers to allow reporting of errors as well as graceful handling in the API response.

Metrics worker concurrent modification issue

Honeybadger keeps raising errors for us due to concurrent modification of the metrics hash in:

https://github.com/honeybadger-io/honeybadger-ruby/blob/master/lib/honeybadger/monitor/worker.rb

It's a race condition, so it's a bit hard to reliably reproduce, but it happens frequently enough.

The problem is that dup'ing a hash requires making an entire copy of it, which means iterating through it. However, there's no lock around this code so other threads are still writing to the hash. On JRuby at least, this results in a RuntimeError: can't add a new key into hash during iteration.

It's possible MRI gets away with this because dup is implemented as native code. I'm not sure what rubinius does.

It was suggested by one of the JRuby core team members that the hamster gem would probably be a good candidate for this, at the expense of an additional dependency:

https://github.com/hamstergem/hamster

Test mode

If you're using they Honeybadger.notify method on non-railsy projects it can be kinda hairy in testing environments. For example:

begin
  raise "I fail" if something_awry
rescue => e
  Honeybadger.notify(e)
end

In a testing environment this is kinda a hidden failure. If the test is simply asserting that a method was called and everything after it works fine, then this would never actually show you that the test had an exception raised.

For my proposal I say that Honeybadger perhaps have a "test" mode where instead of .notify attempting to send to a server, it actually just raises an exception.

For now, in our tests we do:

def Honeybadger.notify(exception)
  raise exception
end

I put this in the spec_helper.rb and my problems are solved. This is mostly food for thought.

Thanks!

Trying to reopen Honeybadger module to add local variable context works in development but not production

I wrote a gem to get the local context that an exception is thrown in, so honeybadger reports will contain the local variables and parameters passed to a given method which is throwing an error.

It works by reopening the Honeybadger module and intercepting calls to .notify().

The meat of the method is here:

https://github.com/tronathan/honeybadger-local-context/blob/master/lib/honeybadger-local-context.rb

Works like a charm in development. Why does this work in development but not in production? (Is my gem being included /before/ the honeybadger gem instead of after? If so, how can one specify?)

Booleans in context are ignored

If I do the following in a before_filter...

Honeybadger.context({
  :debuga => true, 
  :debugb => 'true', 
  :debugc => false, 
  :debugd => 'false'})

...then Honeybadger logs this:

Context
{
  "debugb" => "true",
  "debugd" => "false"
}

The "string booleans" are preserved, but the real booleans are not. This is also true of deeply nested booleans in embedded hashes.

Overwriting api_key through `notice` object is not working

We need to use multiple HB projects in single codebase. README says that api_key can be overwritten via notice.api_key field https://github.com/honeybadger-io/honeybadger-ruby#going-beyond-exceptions

Inconsistent documentation?

On master readme I see:

Honeybadger.notify(
  :error_class   => "Special Error",
  :error_message => "Special Error: #{e.message}",
  :parameters    => params
)

But in master lib/honeybadger.rb I see the signature:

def notify(exception, options = {})

I'm guessing the code version is right? However, it looks like we call the hash version (the one in the readme) in our app and it seems to work fine. Can you help me figure out which form is the right one? Thanks!

Manual notification trigger

Hi there.

I tried to follow your docu to trigger a notification manually to a different Honeybadger project using a different api key. You guys mentioned that any of the following keys can be overridden

{
  :api_key       => Honeybadger.api_key,
  :error_message => 'Notification',
  :backtrace     => caller,
  :parameters    => {},
  :session       => {},
  :context       => {}
}

I went ahead and did this:

Honeybadger.notify(
    :api_key   => "new api key",
    :error_message => "Special Error: #{e.message}"
  )

Unfortunately, it did not work as expected. The notification was still being reported to the Honeybadger project that was previously configured.

Looking at the code, I noticed that the notification is being sent to the Honeybadger.sender previously initialized.

Steps that I assume it takes when reporting to Honeybadger

notify method is called
Notification is built
Built notification is sent
send_notice method calls notice.deliver
deliver method sends the notification to the Honeybadger.sender configured upon initialization

  def deliver
    return false unless Honeybadger.sender
    Honeybadger.sender.send_to_honeybadger(self)
  end

Correct me if I'm wrong but shouldn't it be initializing a new sender when the notify method is called with a new api_key? Or did I miss some important configuration for this to work?

Thanks in advance.

Failure if other gems depend on faraday 0.7.x

I'm getting Faraday errors from all of your 1.9 versions when they try to report an exception. Annoying, because hb has already caught the original error.

The problem is that your gemspec has an open dependence on Faraday while using syntax specific to 0.8. If there are other gems in the application that are ~> 0.7.x, honeybadger will blow up at runtime. In my case that includes both oauth2 and youtube_it.

I don't have a monitoring-worthy account so for now I can pin to 1.8.1, which seems still to work.

Stack trace for you:

Raising 'HoneybadgerTestingException' to simulate application failure.
** [Honeybadger] The optional metrics feature is not enabled for your account.  Try restarting your app or contacting [email protected] if your subscription includes this feature.
** [Honeybadger] Environment Info: [Ruby: 1.9.3] [Rails: 4.0.1] [Env: development]
** [Honeybadger] [Honeybadger::Sender#client] Failure initializing the HTTP connection.
Error: NoMethodError - undefined method `url_prefix=' for #<Faraday::Builder:0x007faadf9fc1f8>
Backtrace:
/Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/honeybadger-1.9.2/lib/honeybadger/sender.rb:124:in `block in client'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/faraday-0.7.6/lib/faraday/connection.rb:46:in `block in initialize'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/faraday-0.7.6/lib/faraday/builder.rb:12:in `block in create'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/faraday-0.7.6/lib/faraday/builder.rb:65:in `build'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/faraday-0.7.6/lib/faraday/builder.rb:54:in `initialize'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/faraday-0.7.6/lib/faraday/builder.rb:12:in `new'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/faraday-0.7.6/lib/faraday/builder.rb:12:in `create'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/faraday-0.7.6/lib/faraday/connection.rb:46:in `initialize'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/faraday-0.7.6/lib/faraday.rb:10:in `new'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/faraday-0.7.6/lib/faraday.rb:10:in `new'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/honeybadger-1.9.2/lib/honeybadger/sender.rb:122:in `client'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/honeybadger-1.9.2/lib/honeybadger/sender.rb:44:in `send_to_honeybadger'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/honeybadger-1.9.2/lib/honeybadger/notice.rb:138:in `deliver'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/honeybadger-1.9.2/lib/honeybadger.rb:152:in `send_notice'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/honeybadger-1.9.2/lib/honeybadger.rb:112:in `notify_or_ignore'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/honeybadger-1.9.2/lib/honeybadger/rails/middleware/exceptions_catcher.rb:18:in `render_exception_with_honeybadger'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/actionpack-4.0.1/lib/action_dispatch/middleware/debug_exceptions.rb:27:in `rescue in call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/actionpack-4.0.1/lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/actionpack-4.0.1/lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/railties-4.0.1/lib/rails/rack/logger.rb:38:in `call_app'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/railties-4.0.1/lib/rails/rack/logger.rb:20:in `block in call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/activesupport-4.0.1/lib/active_support/tagged_logging.rb:67:in `block in tagged'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/activesupport-4.0.1/lib/active_support/tagged_logging.rb:25:in `tagged'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/activesupport-4.0.1/lib/active_support/tagged_logging.rb:67:in `tagged'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/railties-4.0.1/lib/rails/rack/logger.rb:20:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/actionpack-4.0.1/lib/action_dispatch/middleware/request_id.rb:21:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rack-1.5.2/lib/rack/methodoverride.rb:21:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rack-1.5.2/lib/rack/runtime.rb:17:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/activesupport-4.0.1/lib/active_support/cache/strategy/local_cache.rb:83:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rack-1.5.2/lib/rack/lock.rb:17:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/actionpack-4.0.1/lib/action_dispatch/middleware/static.rb:64:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rack-1.5.2/lib/rack/sendfile.rb:112:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/honeybadger-1.9.2/lib/honeybadger/rack.rb:41:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/railties-4.0.1/lib/rails/engine.rb:511:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/railties-4.0.1/lib/rails/application.rb:97:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/honeybadger-1.9.2/lib/honeybadger/rails3_tasks.rb:92:in `block (2 levels) in <top (required)>'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:236:in `call'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:236:in `block in execute'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:231:in `each'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:231:in `execute'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:175:in `block in invoke_with_call_chain'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:168:in `invoke_with_call_chain'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/task.rb:161:in `invoke'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:149:in `invoke_task'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:106:in `block (2 levels) in top_level'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:106:in `each'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:106:in `block in top_level'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:115:in `run_with_threads'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:100:in `top_level'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:78:in `block in run'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:165:in `standard_exception_handling'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/lib/rake/application.rb:75:in `run'
    /Users/will/.rbenv/versions/1.9.3-p429/lib/ruby/gems/1.9.1/gems/rake-10.1.0/bin/rake:33:in `<top (required)>'
    /Users/will/.rbenv/versions/1.9.3-p429/bin/rake:23:in `load'
    /Users/will/.rbenv/versions/1.9.3-p429/bin/rake:23:in `<main>'

Raising rescued exceptions in Development mode

When running in local, honeybadger will not send exceptions which is fine. But it will also swallow manually rescued exceptions without any notices like in the example mentioned here : http://docs.honeybadger.io/article/32-log-ruby-exceptions-already-rescued

Here is the behaviour I would like to see implemented directly in the notify_honeybadger method :

rescue => ex
  if Rails.env.development?
    raise ex  # or logger.error(ex) 
  else
    notify_honeybadger(ex)
  end
  flash[:failure] = 'Encryptions could not be rerouted, try again.'
end

I could of course do this all over my code but it would bloat it and I really think it would be helpful for most developers to see exceptions raised locally. What do you think ?

Honeybadger::Rack should be aware of rack cascade 404s

We started using the Honeybadger::Rack middleware in one of our sinatra apps, and we started getting thousands of Sinatra::NotFound exceptions logged due to "404s" from rack cascade. Our solution was to ignore Sinatra::NotFound exceptions altogether, but it'd be nice if the middleware was rack-cascade-aware.

Honeybadger does not report errors when caught by custom error renderer

Hi there,

I noticed that Honeybadger wasn't reporting errors that were happening in my application. I found the source, but I feel that honeybadger should have still been reporting.

One of my developers added the following code to our application controller

unless Rails.application.config.consider_all_requests_local
    rescue_from Exception, with: lambda { |exception| render_error 500, exception }
    rescue_from ActionController::RoutingError, ActionController::UnknownController, ::AbstractController::ActionNotFound, ActiveRecord::RecordNotFound, with: lambda { |exception| render_error 404, exception }
  end

  private
  def render_error(status, exception)
    respond_to do |format|
      format.html { render template: "errors/error_#{status}", layout: 'layouts/application', status: status }
      format.all { render nothing: true, status: status }
    end
  end

Via this gist he found online: https://gist.github.com/gonzedge/1563416 (which is the first result for custom Rails errors)

I have since removed the rescue_from Exception line and honeybadger is reporting again. Though I don't agree he should have put the rescue_from Exception line in the code, I still feel like Honeybadger should have kept reporting under these circumstances.

Is there a way of rendering custom error pages with Honeybadger still reporting errors? Would point number 3 in this blog post work?

Show parameters to Sidekiq job in Honeybadger UI?

When Honeybadger reports an error that happens in a Rails controller, it shows the parameters that were passed to the controller. How hard would it be to use this section to show the parameters that get passed to a Sidekiq job that causes an error notification?

Use Rails filter paramters instead of static array

honeybadger-ruby/lib/honeybadger/configuration.rb

Line 107 in bca3a1d

DEFAULT_PARAMS_FILTERS = %w(password password_confirmation).freeze

The user already tells a rails app about these paramaters with Rails.application.config.filter_parameters, it seems like using that value would be a more appropriate default.

Workaround:

# config/initializers/honeybadger.rb
(Array(Rails.application.config.filter_parameters) - [:password, :password_confirmation]).each do |param|
  config.params_filters <<  param
end

Add a changelog

It'd be really helpful in determining whether to upgrade and what to watch out for during an upgrade if there was a changelog giving a bird's eye view of the changes in each release.

Manually invoking notifications

Calling Honeybadger.notify with any permutation of hash, exception, etc does not actually notify and returns nil.

taken from: http://docs.honeybadger.io/article/41-manually-sending-exceptions-and-events

begin
  params = {
    # params that you pass to a method that can throw an exception
  }
  my_unpredicable_method(*params)
rescue => e
  Honeybadger.notify(
    :error_class   => "Special Error",
    :error_message => "Special Error: #{e.message}",
    :parameters    => params
  )
end

The following sequence (derived from notice_spec.rb) works:

notice = Honeybadger::Notice.new({
  :api_key => Honeybadger.configuration.api_key,
  :error_class   => "Reporting Test",
  :error_message => 'honeybadger test' })

notice.deliver

Swallowed exceptions

I experienced a really mysterious bug where Honeybadger seems to be catching and not re-raising Rack middleware exceptions.

I've made a simple Rails app that reproduces the bug: https://github.com/benmoss/honeybadger-rack-exception. Just run rails s and hit the server and you'll see the issue.

The gist of it is that it seems that it seems the rack.session hash will raise exceptions on missing keys. In https://github.com/honeybadger-io/honeybadger-ruby/blob/master/lib/honeybadger/notice.rb#L407 the Rack hash is checked for [:data] and is throwing an exception that doesn't get caught, and just results in a 404 from Rails and nothing but

Started GET "/" for 127.0.0.1 at 2014-03-24 11:54:49 -0400

in the logs.

The exception is

ArgumentError: A secret is required to generate an integrity hash for cookie session data. Use config.secret_token = "some secret phrase of at least 30 characters"in config/initializers/secret_token.rb
from /Users/moss/code/app/.gem/ruby/1.9.3/gems/actionpack-3.2.16/lib/action_dispatch/middleware/cookies.rb:319:in `ensure_secret_secure'

which is a real mistake in the app. The problem is that this exception never becomes visible to the user.

Changelog Isn't Up To Date

It looks like the change log hasn't been updated since before the 1.12.0 release. I know it's a pain to maintain these things, but it really is appreciated /me sends hugs

"undefined method `limit=' for #<Honeybadger::Configuration:xxxxx>" when precompiling assets

This is with HoneyBadger 1.9.0.beta1.

In development I don't get this error, but when trying to deploy to production, during asset precompile, I get the error "undefined method `limit=' for #<Honeybadger::Configuration:xxxxx>"

I traced the issue to lib/honeybadger/railtie.rb, line 49. It's invoking a method that seems to be no longer implemented.

Any help you can provide would be great - we'd love to get the new monitoring features from Honeybadger 1.9

Thanks,
Dan

JRuby warning

I just noticed the following warning in my startup logs:

/home/nirvdrum/.rbenv/versions/jruby-1.7.2/lib/ruby/gems/shared/gems/honeybadger-1.5.0/lib/honeybadger/notice.rb:238 warning: instance vars on non-persistent Java type # (http://wiki.jruby.org/Persistence)

I'm not totally sure what's going on, but I wanted to at least file the issue here so you're aware of it. This is on JRuby 1.7.2.

Honeybadger gives a shit about exceptions

honeybadger/sender.rb:64

rescue => e

should be

rescue Exception =>

so that not only StandardErrors are caught. Internal exceptions shouldn't escape from an exception reporting framework.

Rack performance issue

Unless I'm mistaken, this line (linked to tag 1.7.0) is doing way more than it should be:

https://github.com/honeybadger-io/honeybadger-ruby/blob/v1.7.0/lib/honeybadger/rack.rb#L46

I think it can be safely reduced to just Honeybadger.clear!, but before submitting the pull request, I wanted to make sure I'm not missing anything. As written, it appears to potentially initialize a thread-local variable. It always creates a hash object it never uses, because the argument isn't supplied to the context call. And then after all that, it just nils out the thread local anyway.

So, that looks like a bunch of unnecessary work that will eventually bog down the GC due to all these unnecessary object allocations. But if my analysis is wrong, please let me know.

Getting an exception running `rake db:migrate` on heroku

It still seems to run fine, but I see this in the output:

** [Honeybadger] [Honeybadger::Sender#ping] Error: JSON::ParserError - 757: unexpected token at '�'
Backtrace:
/app/vendor/bundle/ruby/2.0.0/gems/json-1.8.1/lib/json/common.rb:155:in `parse'
    /app/vendor/bundle/ruby/2.0.0/gems/json-1.8.1/lib/json/common.rb:155:in `parse'
    /app/vendor/bundle/ruby/2.0.0/gems/honeybadger-1.9.4/lib/honeybadger/sender.rb:74:in `ping'
    /app/vendor/bundle/ruby/2.0.0/gems/honeybadger-1.9.4/lib/honeybadger/railtie.rb:46:in `block in <class:Railtie>'
    /app/vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.15/lib/active_support/lazy_load_hooks.rb:34:in `call'
    /app/vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.15/lib/active_support/lazy_load_hooks.rb:34:in `execute_hook'
    /app/vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.15/lib/active_support/lazy_load_hooks.rb:43:in `block in run_load_hooks'
    /app/vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.15/lib/active_support/lazy_load_hooks.rb:42:in `each'
    /app/vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.15/lib/active_support/lazy_load_hooks.rb:42:in `run_load_hooks'
    /app/vendor/bundle/ruby/2.0.0/gems/railties-3.2.15/lib/rails/application/finisher.rb:59:in `block in <module:Finisher>'
    /app/vendor/bundle/ruby/2.0.0/gems/railties-3.2.15/lib/rails/initializable.rb:30:in `instance_exec'
    /app/vendor/bundle/ruby/2.0.0/gems/railties-3.2.15/lib/rails/initializable.rb:30:in `run'
    /app/vendor/bundle/ruby/2.0.0/gems/railties-3.2.15/lib/rails/initializable.rb:55:in `block in run_initializers'
    /app/vendor/bundle/ruby/2.0.0/gems/railties-3.2.15/lib/rails/initializable.rb:54:in `each'
    /app/vendor/bundle/ruby/2.0.0/gems/railties-3.2.15/lib/rails/initializable.rb:54:in `run_initializers'
    /app/vendor/bundle/ruby/2.0.0/gems/railties-3.2.15/lib/rails/application.rb:136:in `initialize!'
    /app/vendor/bundle/ruby/2.0.0/gems/railties-3.2.15/lib/rails/railtie/configurable.rb:30:in `method_missing'
    /app/config/environment.rb:4:in `<top (required)>'
    /app/vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.15/lib/active_support/dependencies.rb:251:in `require'
    /app/vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.15/lib/active_support/dependencies.rb:251:in `block in require'
    /app/vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.15/lib/active_support/dependencies.rb:236:in `load_dependency'
    /app/vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.15/lib/active_support/dependencies.rb:251:in `require'
    /app/vendor/bundle/ruby/2.0.0/gems/railties-3.2.15/lib/rails/application.rb:103:in `require_environment!'
    /app/vendor/bundle/ruby/2.0.0/gems/railties-3.2.15/lib/rails/application.rb:305:in `block (2 levels) in initialize_tasks'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:236:in `call'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:236:in `block in execute'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:231:in `each'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:231:in `execute'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:175:in `block in invoke_with_call_chain'
    /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:168:in `invoke_with_call_chain'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:197:in `block in invoke_prerequisites'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:195:in `each'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:195:in `invoke_prerequisites'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:174:in `block in invoke_with_call_chain'
    /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:168:in `invoke_with_call_chain'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:161:in `invoke'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:149:in `invoke_task'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:106:in `block (2 levels) in top_level'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:106:in `each'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:106:in `block in top_level'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:115:in `run_with_threads'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:100:in `top_level'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:78:in `block in run'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:165:in `standard_exception_handling'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:75:in `run'
    /app/vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/bin/rake:33:in `<top (required)>'
    /app/vendor/bundle/ruby/2.0.0/bin/rake:23:in `load'
    /app/vendor/bundle/ruby/2.0.0/bin/rake:23:in `<main>'

Test task fails when ApplicationController#current_user method depends on subdomain (or other request data)

When honeybadger_user_info attempts to call current_user, and current_user depends on request-specific data being present, such as an account subdomain, the test task may blow up for some users.

Add `environment_name` in the README.md

I would like to suggest to add environment_name info in the README.md. For me the README and even in the Project Settings in http://honeybadger.io seem to be only focused on Rails, Sinatra and Rack apps. In my case, I'm using it in a standalone ruby application.

Honeybadger.configure do |config|
  config.development_environments << 'staging'
  config.environment_name = ENV['MY_SPECIFIC_SERVER_ENV']
  config.api_key = '...'
end

I had to investigate the source code to check how to define the environment name which is used in development_environments. It wasn't hard, but in my point of view, it could be in the README. I believe that most of the users use Rails, Sinatra or Rack, but some don't.

I also recommend to use the same nomenclature in the README as used in the website. The website has references to Private API Key, in the README it is only API Key, although it can be understandable, sometimes it can lead a confusion. Specially in some cases that you can't test it right now. The README has also some sample API Keys 1234567890abcdef, which are bigger than the Private API Keys used in the website a1aa1111.

Memory leak on JRuby

JRuby application servers that can do hot redeploys will shut down the old JRuby runtime without exiting the process. In the new metrics stuff, honeybadger creates a thread that won't shut down until the process dies. This thread will cause a stopped JRuby runtime to sit around in memory much longer than necessary (they appear to be weakrefs and as such, should eventually be GC'd).

The simple fix is to flag the thread in an at_exit handler. I did this for another project:

https://github.com/wr0ngway/lumber/blob/a35520abace41a87b455b15398be630e7ef5b2da/lib/lumber/level_util.rb#L83

It is not possible to filter sensitive data that appears in URLs or query strings

Although you can filters apply to posted parameters and cookies, if sensitive data appears in a URL (a password reset token for example) then although it is possible to filter this in the 'Params' section of an exception report those parameters will not be filtered from the 'URL' or from the 'Environment' where it may well appear in values for 'REQUEST_URI', 'REQUEST_PATH', 'PATH_INFO', and 'ORIGINAL_FULLPATH' etc.

ArgumentError at /admin/resque/failed wrong number of arguments (4 for 2)

After adding resque-honeybadger to my project I get the following error when I go to the visit the Failed tab in Resque.

Any thoughts on what's going on?

ArgumentError at /admin/resque/failed
wrong number of arguments (4 for 2)
file: base.rb location: each line: 50

Spamming log files

I'm seeing this line multiple times on deploy

** [Honeybadger] The optional metrics feature is not enabled for your account. Try restarting your app or contacting [email protected] if your subscription includes this feature.

I've set up my configuration to turn off metrics, but it still persists

Honeybadger.configure do |config|
  config.api_key  = Settings.honeybadger
  config.feedback = false
  config.metrics  = false
end

List of Deployments

Is there any chance you guys could support an API end point for accessing the list of Deployments you keep in Honeybadger? I can add the support to the gem to retrieve them.

I realize I could store this data myself... but since you guys already do it in such a lovely fashion, why not leverage it there? :)

Rake tasks require Rails

I am trying to evaluate Honeybadger as a replacement for Airbrake in our Sinatra based app. Most of it was drop in replacement, except Rake.

After adding require 'honeybadger/tasks' to my Rakefile I ran into the first problem.

The first thing I encountered was a load error around action_controller/test_process. I forked the project and moved that line into the LoadError rescue that was already there just below it.

Next it seems to go into a fully Rails based process for sending the test exception. At this point I don't see a way forward with the amount of Rails tie in there is here.

Am I using the wrong rake tasks file perhaps?

Rails 4.0.0.beta1 Error in generate

I ran rails generate honeybadger --api-key XXXX on a Rails 4.0.0.beta1 app and got this error:


      create  config/initializers/honeybadger.rb
         run  rake honeybadger:test --trace from "."
** Invoke honeybadger:test (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute honeybadger:test
Configuration:
                  api_key: "43535a63"
        backtrace_filters: [#<Proc:0x00000101aea8b0@/Users/jason/Developer/.rvm/ge
 development_environments: []
         environment_name: "development"
                     host: "api.honeybadger.io"
        http_open_timeout: 2
        http_read_timeout: 5
                   ignore: ["ActiveRecord::RecordNotFound", "ActionController::Rou
        ignore_by_filters: []
        ignore_user_agent: []
            notifier_name: "Honeybadger Notifier"
             notifier_url: "https://github.com/honeybadger-io/honeybadger-ruby"
         notifier_version: "1.5.0"
           params_filters: ["password", "password_confirmation"]
             project_root: #<Pathname:/Users/jason/Dropbox/Current/SafeLinks>
                     port: 443
                 protocol: "https"
               proxy_host: nil
               proxy_pass: nil
               proxy_port: nil
               proxy_user: nil
                   secure: true
use_system_ssl_cert_chain: false
                framework: "Rails: 4.0.0.beta1"
         user_information: "Honeybadger Error {{error_id}}"
   rescue_rake_exceptions: nil
    source_extract_radius: 2
Setting up the Controller.
rake aborted!
You should not use the `match` method in your router without specifying an HTTP method.
If you want to expose your action to GET, use `get` in the router:

  Instead of: match "controller#action"
  Do: get "controller#action"
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/actionpack-4.0.0.beta1/lib/action_dispatch/routing/mapper.rb:193:in `normalize_conditions!'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/actionpack-4.0.0.beta1/lib/action_dispatch/routing/mapper.rb:64:in `initialize'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/actionpack-4.0.0.beta1/lib/action_dispatch/routing/mapper.rb:1425:in `new'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/actionpack-4.0.0.beta1/lib/action_dispatch/routing/mapper.rb:1425:in `add_route'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/actionpack-4.0.0.beta1/lib/action_dispatch/routing/mapper.rb:1404:in `decomposed_match'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/actionpack-4.0.0.beta1/lib/action_dispatch/routing/mapper.rb:1386:in `block in match'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/actionpack-4.0.0.beta1/lib/action_dispatch/routing/mapper.rb:1386:in `each'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/actionpack-4.0.0.beta1/lib/action_dispatch/routing/mapper.rb:1386:in `match'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/honeybadger-1.5.0/lib/honeybadger/rails3_tasks.rb:73:in `block (3 levels) in <top (required)>'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/actionpack-4.0.0.beta1/lib/action_dispatch/routing/route_set.rb:320:in `instance_exec'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/actionpack-4.0.0.beta1/lib/action_dispatch/routing/route_set.rb:320:in `eval_block'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/actionpack-4.0.0.beta1/lib/action_dispatch/routing/route_set.rb:298:in `draw'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/honeybadger-1.5.0/lib/honeybadger/rails3_tasks.rb:72:in `block (2 levels) in <top (required)>'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/task.rb:228:in `call'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/task.rb:228:in `block in execute'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/task.rb:223:in `each'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/task.rb:223:in `execute'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/task.rb:166:in `block in invoke_with_call_chain'
/Users/jason/Developer/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/task.rb:159:in `invoke_with_call_chain'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/task.rb:152:in `invoke'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/application.rb:143:in `invoke_task'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/application.rb:101:in `block (2 levels) in top_level'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/application.rb:101:in `each'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/application.rb:101:in `block in top_level'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/application.rb:110:in `run_with_threads'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/application.rb:95:in `top_level'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/application.rb:73:in `block in run'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/application.rb:160:in `standard_exception_handling'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/lib/rake/application.rb:70:in `run'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/gems/rake-10.0.3/bin/rake:33:in `<top (required)>'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/bin/rake:23:in `load'
/Users/jason/Developer/.rvm/gems/ruby-1.9.3-p194/bin/rake:23:in `<main>'
Tasks: TOP => honeybadger:test
false

unable to detect the Honeybadger API Key from your Heroku environment

1 heroku addons:add honeybadger
2 heroku config | grep HONEYBADGER_API_KEY (returns API KEY)
3 rails generate honeybadger --heroku

ERROR:
Attempting to determine your API Key from Heroku...
WARNING: We were unable to detect the Honeybadger API Key from your Heroku environment.
Your Heroku application environment may not be configured correctly.

undefined method `no_commands' for Thor:Class

I am seeing the following error, when running a local development sidekiq process.

11:35:59 sidekiq.1 | ** [Honeybadger] Exception caught while injecting dependency: NoMethodError -- undefined method `no_commands' for Thor:Class

I have...

  * honeybadger (1.15.0)
  * thor (0.19.1)
  * sidekiq (3.1.4)

I run sidekiq (well, everything in dev) through foreman, with the following Procfile...

web: bundle exec puma -t ${PUMA_MIN_THREADS:-4}:${PUMA_MAX_THREADS:-12} -w ${PUMA_WORKERS:-2} -p $PORT -e ${RACK_ENV:-development}
worker: bundle exec sidekiq --concurrency 5

It appears that sidekiq continues to run without issue.

I can try and get more information if you need. I'm not even sure that honeybadger is at fault here, but all the error messages seem to be coming from honeybadger-ruby code.

[Bug] Wrong error report

Hy,

I have some code that raises a REXML::ParseException :

2012-12-28T18:42:50+00:00 app[web.1]: REXML::ParseException (Missing end tag for 'li' (got "description")
2012-12-28T18:42:50+00:00 app[web.1]: Line: 3
2012-12-28T18:42:50+00:00 app[web.1]: Position: 384
2012-12-28T18:42:50+00:00 app[web.1]: Last 80 unconsumed characters:
2012-12-28T18:42:50+00:00 app[web.1]: ):
2012-12-28T18:42:50+00:00 app[web.1]:   app/models/amv_data.rb:90:in `parse_data'
2012-12-28T18:42:50+00:00 app[web.1]:   app/models/amv_data_by_tag.rb:11:in `get_products'
2012-12-28T18:42:50+00:00 app[web.1]:   app/controllers/products_controller.rb:4:in `tag'

However when the error is reported, both its class and message are lost (line 6 of the following gist):

https://gist.github.com/4400797

Is this a bug ?

The page that raised the error is : http://amv-api.herokuapp.com/?q=gluten

Selective classes notification

Is there a way to tell Honeybadger to be notified when errors occur on specified classes only?

For example I have 2 classes: FooBar and BarFoo, I want Honeybadger to be notified only if the error occurs on FooBar and not on BarFoo

Handle failure to parse Rack parameters

If a user POSTs form-encoded data with a trailing '%' character, rack will fail to parse the form parameters. Honeybadger doesn't handle this exception and fails to submit the exception. See backtrace below:

E, [2013-04-08T14:35:34.252848 #6491] ERROR -- : app error: can't convert nil into Hash (TypeError)
E, [2013-04-08T14:35:34.252974 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/rack-1.3.10/lib/rack/request.rb:202:in `merge'
E, [2013-04-08T14:35:34.253016 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/rack-1.3.10/lib/rack/request.rb:202:in `params'
E, [2013-04-08T14:35:34.253055 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/honeybadger-1.6.1/lib/honeybadger/notice.rb:349:in `rack_env'
E, [2013-04-08T14:35:34.253088 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/honeybadger-1.6.1/lib/honeybadger/notice.rb:95:in `initialize'
E, [2013-04-08T14:35:34.253122 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/honeybadger-1.6.1/lib/honeybadger.rb:157:in `new'
E, [2013-04-08T14:35:34.253154 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/honeybadger-1.6.1/lib/honeybadger.rb:157:in `build_notice_for'
E, [2013-04-08T14:35:34.253221 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/honeybadger-1.6.1/lib/honeybadger.rb:110:in `notify_or_ignore'
E, [2013-04-08T14:35:34.253254 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/honeybadger-1.6.1/lib/honeybadger/rack.rb:36:in `notify_honeybadger'
E, [2013-04-08T14:35:34.253302 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/honeybadger-1.6.1/lib/honeybadger/rack.rb:43:in `rescue in call'
E, [2013-04-08T14:35:34.253337 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/honeybadger-1.6.1/lib/honeybadger/rack.rb:47:in `call'
E, [2013-04-08T14:35:34.253369 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/http_server.rb:528:in `process_client'
E, [2013-04-08T14:35:34.253403 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/http_server.rb:600:in `worker_loop'
E, [2013-04-08T14:35:34.253435 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/http_server.rb:485:in `spawn_missing_workers'
E, [2013-04-08T14:35:34.253467 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/http_server.rb:135:in `start'
E, [2013-04-08T14:35:34.253499 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/bin/unicorn:121:in `<top (required)>'
E, [2013-04-08T14:35:34.253591 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/bin/unicorn:23:in `load'
E, [2013-04-08T14:35:34.253634 #6491] ERROR -- : .../shared/bundle/ruby/1.9.1/bin/unicorn:23:in `<main>'

The airbrake gem handles this by catching the exception to parse the parameters and instead submits the following:

{
  "message" => "failed to call params on Rack::Request -- can't convert nil into Hash"
}

Provide method to detect if configured

Calling Honeybadger.notify(exception) in a dev environment where Honeybadger has not been configured dies with:

NoMethodError - undefined method `send_to_honeybadger' for nil:NilClass:
 .../.bundle/gems/ruby/1.9.1/gems/honeybadger-1.6.1/lib/honeybadger/notice.rb:126:in `deliver'
.../.bundle/gems/ruby/1.9.1/gems/honeybadger-1.6.1/lib/honeybadger.rb:148:in `send_notice'
.../.bundle/gems/ruby/1.9.1/gems/honeybadger-1.6.1/lib/honeybadger.rb:104:in `notify'

Is there a way to detect if Honeybadger has been configured already, aside from testing for the RACK_ENV or other configuration tuning? I'm thinking something like:

Honeybadger.notify(exception) if Honeybadger.configured?

Add Sidekiq support

I'm going to drop native support for error handlers in Sidekiq 3.0, so as to not play favorites and give each error service full control over their own implementation. This includes Honeybadger so you'll need to ship your own Sidekiq 3.0 support.

To be clear, I'll be removing this line:

https://github.com/mperham/sidekiq/blob/master/lib/sidekiq/exception_handler.rb#L13

BugSnag has a sample implementation for their integration here:

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

3.0 has no set release date so you should have plenty of time.

The optional metrics feature is not enabled for your account. Try restarting your app or contacting [email protected] if your subscription includes this feature.

Hey Guys

I see my rails log peppered with this message. Why is that? I don't think I'm even sending any optional metrics.

Are notify calls that send a hash considered optional metrics?

Feature: User Informer

I am missing the feature from Airbrake where the error id can be inserted to the HTML error pages from public HTML.

In Airbrake this is done throught:


This will later be replaced with error id if available.

rake honeybadger:test fails when ActionController is not an App dependency

The Honeybadger test rake test is failing when the rails application doesn't have an ActionController dependency. It is my opinion that if ActionController is not used then a generic notification should be broadcast.

$ bx rails generate honeybadger --api-key [redacted]                                                                                                                      /code/src/services/amigo
      append  config/deploy.rb
      create  config/initializers/honeybadger.rb
         run  rake honeybadger:test --trace from "."
** Invoke honeybadger:test (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute honeybadger:test
rake aborted!
no such file to load -- ./app/controllers/application_controller
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:251:in `require'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:251:in `block in require'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:236:in `load_dependency'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:251:in `require'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/honeybadger-1.2.0/lib/honeybadger/rails3_tasks.rb:16:in `block (2 levels) in <top (required)>'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
/Users/bj/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block (2 levels) in top_level'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block in top_level'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `block in run'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/gems/rake-0.9.2.2/bin/rake:33:in `<top (required)>'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/bin/rake:19:in `load'
/Users/bj/.rvm/gems/ruby-1.9.2-p290@amigo/bin/rake:19:in `<main>'
Tasks: TOP => honeybadger:test
false

Manually calling notify loses parameters if context is set

I have a before_action defined in the controller to include context data for each request.

One of the controller actions invokes a custom library class which calls Honeybadger.notify when it runs into problems. The call looks like this:

Honeybadger.notify(error_class: 'CustomErrorClass', error_message: message, paramaters: params)

In this case, params is a hash that's locally defined within that library class. However, when viewing the error on the site only the context is defined and the params are empty.