Describe the bug
After upgrade from sentry-raven to sentry-ruby, we noticed the random exception RuntimeError: can't add a new key into hash during iteration in middleware reported within middlewares
We never got the exception while using sentry-raven, it only starts happening after the upgrade, and we are still trying to rule out the root cause
Here's the list of all middlewares we have so far
$ rails middleware
use Slowpoke::Middleware # `slowpole`
use Sentry::Rails::CaptureExceptions
use Rack::Cors # `rack-cors`
use Rack::Rewrite
use Rack::Sendfile
use ActionDispatch::Static
use ActionDispatch::Executor
use ActiveSupport::Cache::Strategy::LocalCache::Middleware
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use RequestStore::Middleware
use ActionDispatch::RemoteIp
use Sprockets::Rails::QuietAssets # `sprockets-redirect`
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
use Rack::Timeout
use ScoutApm::ErrorService::Middleware # `scout_apm`
use ActionDispatch::Callbacks
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::Flash
use ActionDispatch::ContentSecurityPolicy::Middleware
use Rack::Head
use Rack::ConditionalGet
use Rack::ETag
use Rack::TempfileReaper
use Warden::Manager
use ScoutApm::Middleware # `scout_apm`
use Sentry::Rails::RescuedExceptionInterceptor
use HttpAcceptLanguage::Middleware # `http_accept_language`
use OmniAuth::Strategies::Facebook
run Application.routes
Backtrace of the exception
RuntimeError: can't add a new key into hash during iteration
from rack/request.rb:79:in `set_header'
from action_dispatch/http/request.rb:299:in `request_id='
from action_dispatch/middleware/request_id.rb:26:in `call'
from rack/method_override.rb:24:in `call'
from rack/runtime.rb:22:in `call'
from active_support/cache/strategy/local_cache_middleware.rb:29:in `call'
from action_dispatch/middleware/executor.rb:14:in `call'
from action_dispatch/middleware/static.rb:127:in `call'
from rack/sendfile.rb:110:in `call'
from action_dispatch/middleware/ssl.rb:74:in `call'
from rack/rewrite.rb:24:in `call'
from rack/cors.rb:100:in `call'
from sentry/rack/capture_exceptions.rb:23:in `block in call'
from sentry/hub.rb:50:in `with_scope'
from sentry-ruby.rb:114:in `with_scope'
from sentry/rack/capture_exceptions.rb:14:in `call'
from slowpoke/middleware.rb:8:in `call'
from scout_apm/instruments/middleware_summary.rb:58:in `call'
from rails/engine.rb:524:in `call'
from puma/configuration.rb:246:in `call'
from puma/request.rb:76:in `block in handle_request'
from puma/thread_pool.rb:337:in `with_force_shutdown'
from puma/request.rb:75:in `handle_request'
from puma/server.rb:431:in `process_client'
from puma/thread_pool.rb:145:in `block in spawn_thread'
To Reproduce
Here's the tricky part, the exception happens randomly, I haven't figured out a way to reproduce the exception 100%.
Expected behavior
Actual behavior
Environment
- Ruby Version: 2.7.2
- SDK Version: 4.1.2 (
sentry-ruby, sentry-rails, sentry-sidekiq enabled)
- Integration Versions (if any):
- Rails: 5.2.4.4
- Sidekiq 6.1.2
Sentry Config
This is not necessary but could be helpful.
Sentry.init do |config|
config.dsn = ENV['SENTRY_DSN']
config.enabled_environments = %w[staging production]
config.release = ENV['GIT_COMMIT']
config.excluded_exceptions += %w[
Rack::Timeout::RequestTimeoutError
ActionController::UnknownFormat
Faraday::TimeoutError
Pundit::NotAuthorizedError
Async::Container::Terminate
Interrupt
Koala::Facebook::ServerError
]
config.breadcrumbs_logger = [:active_support_logger]
config.send_default_pii = true
config.traces_sample_rate = 0.8
end
Describe the bug
After upgrade from
sentry-raventosentry-ruby, we noticed the random exceptionRuntimeError: can't add a new key into hash during iteration in middlewarereported within middlewaresWe never got the exception while using
sentry-raven, it only starts happening after the upgrade, and we are still trying to rule out the root causeHere's the list of all middlewares we have so far
Backtrace of the exception
To Reproduce
Here's the tricky part, the exception happens randomly, I haven't figured out a way to reproduce the exception 100%.
Expected behavior
Actual behavior
Environment
sentry-ruby,sentry-rails,sentry-sidekiqenabled)Sentry Config
This is not necessary but could be helpful.