From e475d92c3be7564cf1fbfa4d8562a4799b31eeef Mon Sep 17 00:00:00 2001 From: Joe Haines Date: Thu, 23 Jul 2020 10:42:00 +0100 Subject: [PATCH] Supress frozen middleware errors in Railtie This should never happen in normal operation, but is possible when running RSpec tests See https://github.com/thoughtbot/factory_bot_rails/issues/303#issuecomment-434560625 and https://github.com/bugsnag/bugsnag-ruby/issues/534 Essentially this happens: 1. RSpec boots Rails 2. Rails boot process errors 3. Rails freezes middleware 4. RSpec moves on to the next test file 5. Bugsnag tries to add middleware but fails because it's frozen 6. The stacktrace blames Bugsnag for this test failure 7. goto 4 Supressing this error doesn't solve the problem as it's likely another frozen error will happen in some other library/component, but we want to avoid people thinking this is caused by Bugsnag. The stacktrace does point out the actual problem, but only in the very first error, which can get buried under the frozen errors that happen for each test file --- lib/bugsnag/integrations/railtie.rb | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/lib/bugsnag/integrations/railtie.rb b/lib/bugsnag/integrations/railtie.rb index 763ab7f16..20dc6347f 100644 --- a/lib/bugsnag/integrations/railtie.rb +++ b/lib/bugsnag/integrations/railtie.rb @@ -67,6 +67,14 @@ class Railtie < ::Rails::Railtie rescue app.config.middleware.use Bugsnag::Rack end + rescue FrozenError + # This can happen when running RSpec if there is a crash after Rails has + # started booting but before we've added our middleware. If we don't ignore + # this error then the stacktrace blames Bugsnag, which isn't accurate as + # the middleware will only be frozen if an earlier error occurs + # See this comment for more info: + # https://github.com/thoughtbot/factory_bot_rails/issues/303#issuecomment-434560625 + Bugsnag.configuration.warn("Unable to add Bugsnag::Rack middleware as the middleware stack is frozen") end ##