-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RackRequest - don't allow it to crash on bad URLs and only load Sidekiq middleware if running under Sidekiq server #289
Conversation
* http://www.rubydoc.info/github/mperham/sidekiq/Sidekiq#server%3F-class_method * Only include Sidekiq middleware if we are running under the Sidekiq server process
Delisa, It was the use statement for Bugsnag::Sidekiq that was causing Bugsnag to On Monday, April 4, 2016, Delisa Mason notifications@github.com wrote:
|
@perldork, the new patch adds a dependency check for Sidekiq, which handles correctly setting app type. This is the same way Bugsnag itself is using the library in production as well as some others. Maybe the crash is unrelated? |
@kattrali - could be, I will try out the 4.0.0 version in the near future and see what happens - if there are issues i'll see about a patch and open a new PR. thanks for your response. |
Sounds good, let me know how it turns out! |
I'm seeing this behavior where API requests are logged with type "sidekiq". To the best of my understanding, bugsnag-ruby loads all the integrations it can find while swallowing load errors, assuming that only the integrations that you've installed will be loaded. But on my Sinatra server, I do need Sidekiq in order to queue Sidekiq jobs. The way I'm reading the code suggests that there's nothing preventing Bugsnag from setting app_type to "sidekiq" on my Sinatra server, when really it should be "rack". Is there something I'm missing here? Thanks for your help! |
My apologies, I figured it out :) |
Ah np, @aquach! |
Discovered while using Bugsnag with Rails:
Sidekiq.server?
test to ensure the middleware is only loaded when running under a Sidekiq process.begin/rescue
statement to keep that from happening so that Rack meta-data still gets sent.Initially applied to 3.0.0 (version we are running), same patches also applied cleanly to master HEAD.