Difficulty configuring Bugsnag in Rails before it configures itself

[csuhta]

Here's an example initializer in Rails:

# config/initializers/bugsnag.rb
puts "Bugsnag initializer reached"
Bugsnag.configure do |config|
  config.logger = Logger.new("/dev/null")
  config.api_key = ENV.fetch("BUGSNAG_API_KEY")
end

The Bugsnag ready message gets logged before this initializer runs:

$ rails c
** [Bugsnag] Bugsnag exception handler 5.5.0 ready
Bugsnag initializer reached
Loading development environment (Rails 5.1.4)

I want to change the Bugsnag logger and/or explicitly configure Bugsnag myself. I do not want the gem to try to automatically detect its own configuration. What is the correct way to do this in Rails and other Ruby environments when using Gemfiles/Rubygems to load this gem?

[Cawllec]

So at the moment there isn't a way to do that in several of supported framework. We're automatically requiring the framework integrations which can trigger off configuration options, such as the railtie integration for rails.

While there's no way to disable this at the moment, if this is requested it's something we could look into adding in the future.

[kattrali]

@csuhta Can you provide some examples of the kinds of configuration you'd like to change up front? Perhaps there are specific options we could provide or options we can better surface in the documentation.

[csuhta]

@kattrali For our use case: We have a lot of nighty/hourly sync processes and rake tasks. I would like to override the Bugsnag logger object to point to a custom logger and sometimes also want to completely silence the gem, including the Bugsnag exception handler X ready message

[kattrali]

Gotcha. That makes a lot of sense. We could potentially support an environment variable (e.g. BUGSNAG_AUTOLOAD or similar) to disable loading extensions though afterwards you'd need to load them manually. Does that approach make sense?

[csuhta]

@kattrali That would be perfect. I'm happy to configure the gem myself if I can cleanly wrest automatic behavior away from it.

[cookrn]

We're currently noticing similar behavior where the Railtie before_initialize runs prior to our Bugsnag initializer which sets the API key. This means on every boot of a non-development environment we see the No valid API key has been set, notifications will not be sent message.

[RobertoSchneiders]

@cookrn We're having the same problem.

[longlostnick]

@cookrn @RobertoSchneiders my fix for now is to just set the key in advance as the environment variable BUGSNAG_API_KEY.

bugsnag-ruby/lib/bugsnag/configuration.rb

Line 76 in 7336834

self.api_key = ENV["BUGSNAG_API_KEY"]

[jfelchner]

@kattrali why did this issue get closed?

[csuhta]

@jfelchner It's now possible to set BUGSNAG_DISABLE_AUTOCONFIGURE in your environment to prevent the gem from configuring itself when it's require-d. See the PR here: #419

[jfelchner]

@csuhta I don't want to disable autoconfiguration, I just don't want a warning telling me that my API key is not valid when I'm setting my API key in the initializer.

[jfelchner]

Can we reopen this issue until this gets fixed?

[snmaynard]

I've reopened this one as a matter of course, but it looks to me like the issue is solved and you are experiencing something else @jfelchner. You are seeing bugsnag log that the api key is invalid, but it's correct? That would be a different issue worth raising a separate issue for to make sure it doesnt get lost. If

[jfelchner]

@snmaynard it's basically the same issue as this whereby Bugsnag is initializing itself before the point in the Rails boot process where Rails reads the Bugsnag configuration block.

And in response to your question, yes, the API key is correct. It's not that Bugsnag doesn't eventually find the API key (it does), but prior to that, it logs that the API key is invalid.

[jfelchner]

Also for some more clarification, if I move the Bugsnag configuration block with the API key in it to the top of my application.rb, no warning. Top of my environments/development.rb? No warning. config/initializers/bugsnag.rb? Warning. config/initializers/00_bugsnag.rb Warning.

The reason you're probably not seeing this is because you're probably setting your API_KEY environment variable. We are not. We keep our settings secure with chamber. As @ifightcrime mentioned above, because the code sets the api_key extra early if it's set in an ENV variable, the code path where this warning is shown would be missed for a lot of your users.

[pbougie]

I'm also experiencing problems configuring Bugsnag in a Rails initializer. Setting the API key there does nothing. It has to be done earlier. The opening example is misleading:

# config/initializers/bugsnag.rb
Bugsnag.configure do |config|
  config.api_key = ENV.fetch("BUGSNAG_API_KEY")
  ...
end

The API key is not being set here. Rather it's using ENV["BUGSNAG_API_KEY"] directly when Bugsnag is loaded.

I'm currently using Rails 5.2 RC2 with the new Credentials feature (I'm moving away from using ENV variables for atomic deploys). I tried the following:

# config/initializers/bugsnag.rb
Bugsnag.configure do |config|
  config.api_key = Rails.application.credentials.bugsnag_api_key
end

This unfortunately does not work because the initializer is executed too late. I get the following warning with this configuration: "No valid API key has been set, notifications will not be sent".

If I move the same configuration to application.rb, it begins working, e.g.:

# config/application.rb
Bugsnag.configure do |config|
  config.api_key = Rails.application.credentials.bugsnag_api_key
end

The rest of the configuration can be set in config/initializers/bugsnag.rb. Does not make for a clean implementation.

[jfelchner]

As per my comment here: #438 (comment) can we reopen this until it is adequately fixed?

[Cawllec]

@jfelchner a change has been made into how the API key validity is logged, which will be released shortly. This will fix the issues as noted here.