honeybadger-io / honeybadger-ruby Goto Github PK
View Code? Open in Web Editor NEWRuby gem for reporting errors to honeybadger.io
Home Page: https://docs.honeybadger.io/lib/ruby/
License: MIT License
Ruby gem for reporting errors to honeybadger.io
Home Page: https://docs.honeybadger.io/lib/ruby/
License: MIT License
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.
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.
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>'
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
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?)
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
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
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?
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.
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.
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.
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
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>'
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? :)
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?
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.
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.
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?
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!
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"
}
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:
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 calledsend_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.
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
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
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:
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?
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:
<!-- AIRBRAKE ERROR -->
This will later be replaced with error id if available.
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>`
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
.
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.
Is there a way to ignore the development environments, and just send the notification? Based on the code, it does not look like there is.
Reason: I would like to smoke test things on a staging server (which is included in the dev environments), but no notifications are sent.
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
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
Our application relies on parsing the body payload from POST requests (and PUT) and exceptions can often be thrown due to invalid payloads. We would like to capture these payloads on an exception so that we can tell what input caused the exception.
AFAICT, Honeybadger does not capture the body payload on a POST request. In this case, the body is an 'application/json' formatted string.
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.
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.
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.
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.
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?
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!
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
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.
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.
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
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
I'm seeing the following exception:
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 ?
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.
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
❯ 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'
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.