honeybadger-ruby: can't get error reporting from rake tasks

if $0 =~ /rake/
  require 'honeybadger/init/ruby'
elsif defined?(::Rails::Railtie)
  require 'honeybadger/init/rails'

Hypothetical problem, if the rake task in a Rails app does have an :environment dependency, it’s the init/rails code that should probably be run. Now the difference between effect of init/rails and init/ruby are actually fairly minor, so it may not matter. One potential difference, a slight difference in paths that the honeybadger.yml is looked for. But it might wind up being awfully confusing on the edge case if honeybadger in your rails app normally finds your honeybadger.yml , but not when running rake tasks.

One solution is maybe concurrency-safe flags for “exit_handler_installed?” and/or “honeybadger_init’d?”. And Agent.notify has to check for each of these at the beginning, and do em if they weren’t done already. On every call, which is sad, so maybe that’s no good. But I can’t think of any other safe way to do things at present.

If you did do that, then you might not even need the separate init paths for rails/sinatra/rake. The single lazy init on every notify might be enough. Simplifying code a bit. But at the cost of checking the flags on every notify, which is potentially expensive only because it needs to be concurrency-safe so involve a mutex.

But okay, enough for tonight, I’ll let you and team think on this!

Quick update: I am working on a fix which makes Honeybadger.init idempotent and adds a custom hidden rake task honeybadger:init as a dependency to all the rake tasks giving us a hook where we can test if the rails environment was actually loaded. I just need to clean up the code and add a few tests.

I still think looking at the code that the most straightforward solution is some kind of concurrency-safe flag for “has been initialized”. If running in an app with Rails::Railstie (ie honeybadger decides it’s rails), and a rake task is executed, and the flag is still false, that’s how you know rails hasn’t booted (which would trigger the usual rails honeybadger init), and you need to do the honeybadger init now.

For purpose of “it’s not installing the at_exit handler cause it thinks it’s sinatra when it’s not” bug – I wonder if you just gotta make the client explicitly configure framework in config, to tell honeybadger what framework. That’d be unfortunate. Or maybe at least allow this as a force when the auto-detect code gets confused. I guess the trick there is at present the framework-specific-initialization code runs before any config is read, and config won’t be read if the framework-specific-initialization isn’t done right, which is part of the problem I was running into.