Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

no longer auto-initialize for rails #132

wants to merge 1 commit into


None yet
3 participants

Authors should be free to include airbrake without airbrake automatically including itself into ActiveRecord::Base or injecting itself into Rack middleware.

My apologies for the duplicate issue. My pull request seems to have automatically opened this new issue. I guess I'll leave it open since it has the pull request attached.


shime commented Oct 23, 2012

Could you explain this a little more? What happened? This seems like unnecessary overhead since every user will have to call the initialization now.

It would be better if we provide an option to opt-out the default initialization process instead, wouldn't it?

We have some sensitive data that should not be recorded via airbrake so the default rails integration is unwanted in our case. In one particular case, the automatically configured rack middleware relays all environment data when there is an uncaught exception.

I'd be ok with an opt-out approach for the automatic configuration. If you're interested in my opinions on why one library should not alter classes or configurations of another library, I'm happy to share them.

One nice solution would be to have one 'airbrake' gem that does nothing but provide airbrake libraries, and one 'airbrake-rails' gem that depends on 'airbrake' and does all the fancy auto-configuration stuff.


shime commented Nov 9, 2012

Hey @stevecrozz!

Sorry for not responding earlier. I could add the option to the configuration that opts-out autoloading, but I think a better approach would be to add the environment_filter option. So that you can add the evn variables you wish not to get reported to Airbrake.

How does that sound?

@ghost ghost assigned shime Nov 9, 2012

Hi @shime, environment filter does sound useful, but I would still really like the option to opt-out of autoloading.

Basically, I want to use airbrake from rails just like I would from a non-rails project so that my app can maintain meticulous control over its error handling. After some initial configuration, the only airbrake interface I need is Airbrake#notify.


shime commented May 21, 2013

@stevecrozz just to let you know that I'm working on adding this feature. It's not an easy task since a lot of stuff depends on auto-initialization, but it would be a good feature to have because it would make the gem more customizable, which is something you need and you could also gain on application boot time.

I'll close this one when I'm done, thanks for bringing this up in the first place!

It might just be the case that the airbrake gem has a different design philosophy than the one I'm after. I ended up creating a much smaller gem to use instead of airbrake called 'hydraulic_brake':

Its basically just a stripped down version of airbrake. I'm currently testing it with a bunch of projects and have seen good results so far. I think an approach like hydraulic_brake would be an excellent 'core' to wrap a bunch of nicer functionality around, and I'd be happy to help out with that or work together in some way if you guys are interested.


dvdplm commented Sep 24, 2014

@stevecrozz I think it's a really cool lib you have there and from a quick glance at the code I'm seeing plenty of good changes. Testing the airbrake gem is, as you have noticed, quite painful.
I don't think we can drop the auto init stance that airbrake has had now for so many years, it's a default too many people rely on.
I am, however, very much interested in seeing PRs adding the opt-out behavior discussed above (and any other cool improvements ofc!).

Thanks for bringing this up.

@dvdplm dvdplm closed this Sep 24, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment