rollbar / rollbar-gem Goto Github PK
View Code? Open in Web Editor NEWException tracking and logging from Ruby to Rollbar
Home Page: https://docs.rollbar.com/docs/ruby
License: MIT License
Exception tracking and logging from Ruby to Rollbar
Home Page: https://docs.rollbar.com/docs/ruby
License: MIT License
Enabled via config, matters in particular for Heroku or other platforms where an empty response results in an error page.
Working on #21 for my amusement I've broken the with broken request should report uncaught exceptions
spec in /spec/requests/home_spec.rb. But the problem is, that the spec error was different nearly every time. Here is how you can reproduce it (you should run it on my kavu/ratchetio-gem@6680f71392d8be1ba00c54452f0ce56b32b94c08 or #21):
$ RAILS_ENV=test bundle exec rspec spec/requests --seed 1
Rack::File headers parameter replaces cache_control after Rack 1.5.
HomeController
with broken request
should report uncaught exceptions (FAILED - 1)
with error hiding deep inside
should report uncaught exceptions
Failures:
1) HomeController with broken request should report uncaught exceptions
Failure/Error: exception_info = Ratchetio.last_report[:body][:trace][:exception]
NoMethodError:
undefined method `[]' for nil:NilClass
# ./spec/requests/home_spec.rb:21:in `block (3 levels) in <top (required)>'
Finished in 1.52 seconds
2 examples, 1 failure
Failed examples:
rspec ./spec/requests/home_spec.rb:18 # HomeController with broken request should report uncaught exceptions
Randomized with seed 1
and
$ RAILS_ENV=test bundle exec rspec spec/requests --seed 35472
Rack::File headers parameter replaces cache_control after Rack 1.5.
HomeController
with error hiding deep inside
should report uncaught exceptions
with broken request
should report uncaught exceptions (FAILED - 1)
Failures:
1) HomeController with broken request should report uncaught exceptions
Failure/Error: exception_info[:class].should == 'ArgumentError'
expected: "ArgumentError"
got: "NoMethodError" (using ==)
# ./spec/requests/home_spec.rb:22:in `block (3 levels) in <top (required)>'
Finished in 1.35 seconds
2 examples, 1 failure
Failed examples:
rspec ./spec/requests/home_spec.rb:18 # HomeController with broken request should report uncaught exceptions
Randomized with seed 35472
I suggest that this spec isn't isolated properly, and that's why spec's seed changes specs behavior.
Of course, it may be my mistake but I hope we all together can figure out what's the real problem.
Upgrading from 0.10.14 to 0.11.7 caused NoMethodErrors in my Rails application.
As for now, when exception is raised somewhere in middlewares (hence no controller, parsed request and all that), we don't have much info in ratchet. Basically, all we have is exception message and backtrace.
It'd be great to dump request's env into ratchet, but it doesn't play well with ratchet's reporting API without doing env parsing by hand.
Am I missing something here? If not, I'd try to implement basic data extraction from environment.
I'm got this gem setup in my Rails app, but it doesn't seem to catch errors inside of Rake tasks:
task :cron_task => :environment do
raise "error in cron task"
end
doesn't report anything on Ratchet, but this works:
task :cron_task => :environment do
begin
raise "error in cron task"
rescue Exception => e
Ratchetio.report_exception(e)
end
end
Is this by design? It looks like this gem taps into some Rack middleware to catch exceptions which would explain why it doesn't work for Rake tasks, is there a recommended way to have it catch all my Rake tasks?
Since ~ v0.12.4 the "request_data[:route]" value is now assumed to be a hash (https://github.com/rollbar/rollbar-gem/blob/master/lib/rollbar.rb#L91). As mentioned in the Padrino issue (#79) this breaks the convention of adding the path to that data via a custom RequestDataExtractor. It may even cause an error that itself get reported to Rollbar ("no implicit conversion of Symbol into Integer").
With the Rails-centric assumptions, the values in my route hash are all nil, which results in a context of "#" for every occurrence.
Hi,
I'm currently having an issue with a server which has unreliable network connectivity. However, the issues are not reported by rollbar. My guess is the server cannot reach the rollbar server when the error happened.
Is there any way to provide a fallback if notifying rollbar fails? I'd like to be able to at least save the data somewhere. Is there anything like this?
Best Regards,
Fabian
Could someone point me to a Padrino configuration example? I am trying to use Rollbar on Heroku (and locally for testing) with a Padrino app. There is no Rails generate for Padrino so I created the config/initializers/rollbar.rb file manually and put my access token into it) but I get an error when trying to run the rake test (rake doesn't know how to execute the task which seems to indicate that some configuration is missing) and I don't see any data being collected from local errors in my app.
Thanks.
See collectiveidea/delayed_job#616 for history.
If there's an exception in Rollbar.report_exception
or Rollbar.report_message
, we should (at least attempt to) report that exception to Rollbar.
Doing this correctly probably means lots of begin-rescue blocks inside report_exception
and report_message
. There should also be a final failsafe response that doesn't rely on any dynamic data, to be sent as a last resort.
Currently, when sending a failsafe, there's no indication of where the actual problem came from and thus no way to debug it. If the payload is too large, we should at least log it locally (via the Rails log or whatever is available).
Gem releases don't seem to be tagged in git, which makes it much more difficult to work out whether a particular feature has made it into the version I'm using.
I have code like this in my web app:
# ...
rescue => e
Rollbar.report_exception(e)
# ...
end
In the logs, I'm seeing this error:
Error reporting exception to Rollbar: undefined method '[]' for nil:NilClass
Is there anyway I can get a backtrace or more explicit debugging info from the gem? Could the surrounding code somehow cause side-effects? Any help on where to look would be much appreciated :-)
Via @sagmor:
If the content-type is application/json, this gem currently doesn't collect anything useful about the request body. We should collect this data and pass it with the request data, maybe as request.json
.
When reporting an exception, we are able to include person data, which then shows up under the People tab. It would be helpful if we could also include person data when reporting a message, and also have it appear under the People tab.
The current workaround is to wrap the message in an exception, but this feels wrong, and it makes it more difficult to include extra data.
My initial thought for an implementation is to check if :person
is in the extra data hash, and if so, remove it from the hash and add it as the :person
data.
If this seems like a good idea, I'm happy to submit a pull request.
I have rollbar disabled in development, but any time there's an exception I get log messages like this:
[Rollbar] Reporting exception: undefined method `submissions' for nil:NilClass
[Rollbar] Exception not reported because Rollbar is disabled
It would be nice if there was a way to disable these as they clutter up my log file and are unnecessary if Rollbar is disabled.
I integrated the rollbar gem in a non-rails/active-support project with this snippet 1. After upgrading from 0.11.7 to 0.12.8, the Rollbar.report_exception
call fails with the following exception:
NoMethodError: undefined method `present?' for nil:NilClass
File "<snip>/vendor/bundle/ruby/2.0.0/gems/rollbar-0.12.8/lib/rollbar.rb" line 80 in report_exception
The present?
check was introduced in 2
We haven't upgraded our DelayedJob gem yet. Because I'm scared, and lazy.
RatchetIO 0.5.0 finds DelayedJob, but then tries to bind to something only present in DJ 3: Delayed::Plugins::Plugin
.
Can it be changed so that if DJ is present but the Plugin
class isn't a warning is issued?
We get a lot of junk requests to bad urls. We know they're not coming from our site - they're just from script kiddies.
We looked into capturing (and ignoring) these errors in our app, but it seems like there are few problems with that.
One possible solution would be to change Rollbar#filtered_level to call procs if they are passed in. That might look something like this in an app's config:
config.exception_level_filters.merge!(
'MyCriticalException' => 'critical',
'ActionController::RoutingError' => lambda { |e| e.message.include?('/flex.atdmt.com/mstag') ? 'ignore' : 'warning' })
What do you guys thinks of this? I'm not really interested in starting on a PR if there's no chance it'll be merged to mainline, so let me know if it's something you'd be interested in.
All our server error reports were failing with an error. This meant nothing was arriving in rollbar.
[Rollbar] Error reporting exception to Rollbar: not opened for reading
That error was being thrown in rollbar.rb (0.8.3) at line 307
MultiJson.dump(payload)
The reason was eventually chased to this line in ActiveSupport encoding.rb , which indicated one part of the payload did not serialize to json, and did not fail gracefully.
module Enumerable
def as_json(options = nil) #:nodoc:
to_a.as_json(options)
end
end
Inspecting self at that point showed that the object that was attempting to be written out as json was STDERR. The presence of a STDERR in the payload object was traced to:
#<ActionDispatch::Request:
@env=
{"SERVER_SOFTWARE"=>"thin 1.5.1 codename Straight Razor",
"rack.input"=>#<StringIO:0x0000000926e428>,
"rack.version"=>[1, 0],
"rack.errors"=>#<IO:<STDERR>>,
So... All told, to get our exceptions to be reported to rollbar, we have to do this:
rack.errors = ''
Rollbar.report_exception(exception, request)
(Wrapped in an ensure to set them back afterward of course).
I hope this helps anyone else is seeing the same issue. Or if someone can tell us why just we might be seeing it, that would be great.
Incidentally, it is exactly the problem described here: https://thin.lighthouseapp.com/projects/7212/tickets/114-requestenvto_json-fails
But it also happens outside of Thin.
If an error occurs on a file upload, such as in a video upload form, then the entire payload is sent to Ratchet. I don't want this, and I'm sure you don't want this either. The file I tested was only 4.5 MB, but took a good minute to upload before the exception displayed. During this time, the log displayed [Ratchet.io] Sending payload
For form data payloads greater than a few kilobytes (50KB a good threshold perhaps?), or for all File fields, the content should be truncated or replaced with a placeholder such as [File - Content-Type: video/mp4]
As an aside, I'm pretty sure that when this happens, Ratchet.io isn't handling the Item correctly either. The exception did not show up in my account after it occurred.
Since we can use capistrano to deploy any type of project doesn't make a lot of sense using variable rails_env to tell rollbar gem what environment we are deploying.
Accepting rails_env if available is not a bad solution, but it would be cool to be able to override its value with a more generic variable, like project_env, rollbar_env....
I can do a pull request if you accept to override the env value with another variable
Thanks
Would you be open to a PR adding :on_error => :continue
to the capistrano task?
Today we ran into a problem with our deploys being rolled back because communication with the deploy API timed out.
I'd prefer not to have external service availability affect our deploys...
Some production environments (nginx?) send the real hostname, port, and protocol in X-Forwarded headers, which we currently don't look for. We should update rollbar_url
:
https://github.com/rollbar/rollbar-gem/blob/master/lib/rollbar/request_data_extractor.rb#L54-L63
to look for the following headers:
and adjust the url appropriately if they are present.
The current implementation for the Delayed::Job plugin uses the invoke_job
event. However, this does not allow job objects that implement an error
handler to do the driving. For example:
module MyJob
def perform
# ...
end
def error(job, exception)
Rollbar.report_exception(exception) if i_say_so?
end
end
This would never stop rollbar exceptions from happening. Thoughts?
The idea is that the gem is usable outside of rails, so ideally we shouldn't depend on things like Object#try
.
Per discussion with @aconbere in IRC, we should be setting a timeout. Relevant code is here: https://github.com/rollbar/rollbar-gem/blob/master/lib/rollbar.rb#L343-L369
Hi,
I'm not sure this is a rollbar issue, but it's the only dependency turning up in the stacktrace. I'm using version 0.11.7
- I know there are newer versions, but I hesitate to update because there were quite a few regressions.
Here's the stacktrace:
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 130 in unpack
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 130 in block in escape
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 125 in gsub
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 125 in escape
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 69 in escape
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 177 in encode_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 48 in block in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 77 in check_for_circular_references
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 46 in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in block in encode_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in each
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in map
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in encode_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 48 in block in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 77 in check_for_circular_references
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 46 in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in block in encode_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in each
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in map
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in encode_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 48 in block in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 77 in check_for_circular_references
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 46 in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in block in encode_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in each
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in map
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in encode_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 48 in block in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 77 in check_for_circular_references
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 46 in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in block in encode_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in each
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in map
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in encode_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 48 in block in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 77 in check_for_circular_references
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 46 in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in block in encode_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in each
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in map
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 252 in encode_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 48 in block in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 77 in check_for_circular_references
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 46 in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/json/encoding.rb" line 31 in encode
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/core_ext/object/to_json.rb" line 16 in to_json
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/multi_json-1.8.4/lib/multi_json/adapters/json_common.rb" line 21 in dump
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/multi_json-1.8.4/lib/multi_json/adapter.rb" line 24 in dump
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/multi_json-1.8.4/lib/multi_json.rb" line 137 in dump
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rollbar-0.11.7/lib/rollbar.rb" line 338 in build_payload
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rollbar-0.11.7/lib/rollbar.rb" line 89 in report_exception
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rollbar-0.11.7/lib/rollbar/exception_reporter.rb" line 9 in report_exception_to_rollbar
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rollbar-0.11.7/lib/rollbar/middleware/rails/show_exceptions.rb" line 22 in rescue in call_with_rollbar
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rollbar-0.11.7/lib/rollbar/middleware/rails/show_exceptions.rb" line 19 in call_with_rollbar
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/actionpack-3.2.16/lib/action_dispatch/middleware/show_exceptions.rb" line 56 in call
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/railties-3.2.16/lib/rails/rack/logger.rb" line 32 in call_app
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/railties-3.2.16/lib/rails/rack/logger.rb" line 16 in block in call
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/tagged_logging.rb" line 22 in tagged
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/railties-3.2.16/lib/rails/rack/logger.rb" line 16 in call
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/actionpack-3.2.16/lib/action_dispatch/middleware/request_id.rb" line 22 in call
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/methodoverride.rb" line 21 in call
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/runtime.rb" line 17 in call
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/activesupport-3.2.16/lib/active_support/cache/strategy/local_cache.rb" line 72 in call
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/lock.rb" line 15 in call
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb" line 136 in forward
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb" line 143 in pass
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb" line 155 in invalidate
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb" line 71 in call!
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb" line 51 in call
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/railties-3.2.16/lib/rails/engine.rb" line 484 in call
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/railties-3.2.16/lib/rails/application.rb" line 231 in call
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/railties-3.2.16/lib/rails/railtie/configurable.rb" line 30 in method_missing
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/unicorn-4.2.1/lib/unicorn/http_server.rb" line 530 in process_client
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/unicorn-4.2.1/lib/unicorn/http_server.rb" line 604 in worker_loop
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/unicorn-4.2.1/lib/unicorn/http_server.rb" line 487 in spawn_missing_workers
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/unicorn-4.2.1/lib/unicorn/http_server.rb" line 137 in start
File "/path/to/app/shared/bundle/ruby/1.9.1/gems/unicorn-4.2.1/bin/unicorn" line 121 in <top (required)>
File "/path/to/app/shared/bundle/ruby/1.9.1/bin/unicorn" line 23 in load
File "/path/to/app/shared/bundle/ruby/1.9.1/bin/unicorn" line 23 in <main>
Thanks!
Fabian
We have a Rails 3 project that utilizes Authlogic for authentication. When I was setting up the Rollbar gem, I ran heroku run rake rollbar:test --app [APP_NAME]
and got the follow output.
You'll notice that it throws an exception because Authlogic doesn't get initialized when the Rollbar test is run. This causes a hangup during the setup process of Rollbar because Rollbar doesn't think the notifier has been setup and won't move beyond that setup step in the dashboard.
I'm sure other projects still utilize Authlogic and will run into this error.
Setting up the controller.
Processing...
Cache read: http://www.example.com/verify?
Dalli::Server#connect mc2.dev.ec2.memcachier.com:11211
Dalli/SASL authenticating as 255de5
Dalli/SASL: 255de5
Started GET "/verify" for at 2013-10-17 15:52:56 +0000
Raising RollbarTestingException to simulate app failure.
RollbarTestingException (Testing rollbar with "rake rollbar:test". If you can see this, it works.):
vendor/bundle/ruby/2.0.0/gems/rollbar-0.11.4/lib/rollbar/rake_tasks.rb:37:in `test_rollbar'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:407:in `_run__1297649386175370641__process_action__4365661031264405793__callbacks'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:405:in `__run_callback'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:385:in `_run_process_action_callbacks'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:81:in `run_callbacks'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/abstract_controller/callbacks.rb:17:in `process_action'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_controller/metal/rescue.rb:29:in `process_action'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_controller/metal/instrumentation.rb:30:in `block in process_action'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/notifications.rb:123:in `block in instrument'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/notifications.rb:123:in `instrument'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_controller/metal/instrumentation.rb:29:in `process_action'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_controller/metal/params_wrapper.rb:207:in `process_action'
vendor/bundle/ruby/2.0.0/gems/activerecord-3.2.12/lib/active_record/railties/controller_runtime.rb:18:in `process_action'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/abstract_controller/base.rb:121:in `process'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/abstract_controller/rendering.rb:45:in `process'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_controller/metal.rb:203:in `dispatch'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_controller/metal/rack_delegation.rb:14:in `dispatch'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_controller/metal.rb:246:in `block in action'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/routing/route_set.rb:73:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/routing/route_set.rb:73:in `dispatch'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/routing/route_set.rb:36:in `call'
vendor/bundle/ruby/2.0.0/gems/journey-1.0.4/lib/journey/router.rb:68:in `block in call'
vendor/bundle/ruby/2.0.0/gems/journey-1.0.4/lib/journey/router.rb:56:in `each'
vendor/bundle/ruby/2.0.0/gems/journey-1.0.4/lib/journey/router.rb:56:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/routing/route_set.rb:601:in `call'
vendor/bundle/ruby/2.0.0/gems/omniauth-1.1.1/lib/omniauth/strategy.rb:177:in `call!'
vendor/bundle/ruby/2.0.0/gems/omniauth-1.1.1/lib/omniauth/strategy.rb:157:in `call'
vendor/bundle/ruby/2.0.0/gems/omniauth-1.1.1/lib/omniauth/builder.rb:48:in `call'
vendor/bundle/ruby/2.0.0/gems/rack-timeout-0.0.3/lib/rack/timeout.rb:16:in `block in call'
vendor/ruby-2.0.0/lib/ruby/2.0.0/timeout.rb:66:in `timeout'
vendor/bundle/ruby/2.0.0/gems/rack-timeout-0.0.3/lib/rack/timeout.rb:16:in `call'
vendor/bundle/ruby/2.0.0/gems/mongoid-3.0.19/lib/rack/mongoid/middleware/identity_map.rb:34:in `block in call'
vendor/bundle/ruby/2.0.0/gems/mongoid-3.0.19/lib/mongoid/unit_of_work.rb:39:in `unit_of_work'
vendor/bundle/ruby/2.0.0/gems/mongoid-3.0.19/lib/rack/mongoid/middleware/identity_map.rb:34:in `call'
vendor/bundle/ruby/2.0.0/gems/warden-1.2.1/lib/warden/manager.rb:35:in `block in call'
vendor/bundle/ruby/2.0.0/gems/warden-1.2.1/lib/warden/manager.rb:34:in `catch'
vendor/bundle/ruby/2.0.0/gems/warden-1.2.1/lib/warden/manager.rb:34:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/best_standards_support.rb:17:in `call'
vendor/bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/etag.rb:23:in `call'
vendor/bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/conditionalget.rb:25:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/head.rb:14:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/params_parser.rb:21:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/flash.rb:242:in `call'
vendor/bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/session/abstract/id.rb:210:in `context'
vendor/bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/session/abstract/id.rb:205:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/cookies.rb:341:in `call'
vendor/bundle/ruby/2.0.0/gems/activerecord-3.2.12/lib/active_record/query_cache.rb:64:in `call'
vendor/bundle/ruby/2.0.0/gems/activerecord-3.2.12/lib/active_record/connection_adapters/abstract/connection_pool.rb:479:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/callbacks.rb:28:in `block in call'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:405:in `_run__540681950509507063__call__2905980800882944156__callbacks'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:405:in `__run_callback'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:385:in `_run_call_callbacks'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:81:in `run_callbacks'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/callbacks.rb:27:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/remote_ip.rb:31:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/debug_exceptions.rb:16:in `call'
vendor/bundle/ruby/2.0.0/gems/rollbar-0.11.4/lib/rollbar/middleware/rails/show_exceptions.rb:19:in `call_with_rollbar'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
vendor/bundle/ruby/2.0.0/gems/railties-3.2.12/lib/rails/rack/logger.rb:32:in `call_app'
vendor/bundle/ruby/2.0.0/gems/railties-3.2.12/lib/rails/rack/logger.rb:16:in `block in call'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/tagged_logging.rb:22:in `tagged'
vendor/bundle/ruby/2.0.0/gems/railties-3.2.12/lib/rails/rack/logger.rb:16:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/request_id.rb:22:in `call'
vendor/bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/methodoverride.rb:21:in `call'
vendor/bundle/ruby/2.0.0/gems/rack-1.4.5/lib/rack/runtime.rb:17:in `call'
vendor/bundle/ruby/2.0.0/gems/activesupport-3.2.12/lib/active_support/cache/strategy/local_cache.rb:72:in `call'
vendor/bundle/ruby/2.0.0/gems/actionpack-3.2.12/lib/action_dispatch/middleware/static.rb:62:in `call'
vendor/bundle/ruby/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:136:in `forward'
vendor/bundle/ruby/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:245:in `fetch'
vendor/bundle/ruby/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:185:in `lookup'
vendor/bundle/ruby/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:66:in `call!'
vendor/bundle/ruby/2.0.0/gems/rack-cache-1.2/lib/rack/cache/context.rb:51:in `call'
vendor/bundle/ruby/2.0.0/gems/railties-3.2.12/lib/rails/engine.rb:479:in `call'
vendor/bundle/ruby/2.0.0/gems/railties-3.2.12/lib/rails/application.rb:223:in `call'
vendor/bundle/ruby/2.0.0/gems/rollbar-0.11.4/lib/rollbar/rake_tasks.rb:58:in `block (2 levels) in <top (required)>'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:236:in `call'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:236:in `block in execute'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:231:in `each'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:231:in `execute'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:175:in `block in invoke_with_call_chain'
vendor/ruby-2.0.0/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:168:in `invoke_with_call_chain'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/task.rb:161:in `invoke'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:149:in `invoke_task'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:106:in `block (2 levels) in top_level'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:106:in `each'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:106:in `block in top_level'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:115:in `run_with_threads'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:100:in `top_level'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:78:in `block in run'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:165:in `standard_exception_handling'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/lib/rake/application.rb:75:in `run'
vendor/bundle/ruby/2.0.0/gems/rake-10.1.0/bin/rake:33:in `<top (required)>'
vendor/bundle/ruby/2.0.0/bin/rake:23:in `load'
vendor/bundle/ruby/2.0.0/bin/rake:23:in `<main>'
[Rollbar] Reporting exception: Testing rollbar with "rake rollbar:test". If you can see this, it works.
[Rollbar] Exception while reporting exception to Rollbar: You must activate the Authlogic::Session::Base.controller with a controller object before creating objects
It would be nice if the try
method was not used. For example:
rollbar_debug "[Rollbar] Reporting exception: #{exception.try(:message)}", :error
could be:
rollbar_debug "[Rollbar] Reporting exception: #{exception.respond_to?(:message) ? exception.message : ''}", :error
That way active support (or at least the try portion of active support) would not be needed to use this gem.
Thanks!
We run with rollbar disabled in development and it would be nice if I could set a flag that would write exceptions and parameters to the log if Rollbar is disabled.
Allow fine-grained control over which reports are ignored, similar to rollbar.js
Rails has an internal rack middleware, which manages closing the database connections when necessary.
From what I'm experiencing, it would seem when an exception is triggered by rollbar, this middleware isn't executed anymore.
This quickly leads to ActiveRecord::ConnectionTimeoutError: could not obtain a database connection within 5.000 seconds (waited 5.000 seconds)
since the postgresql server has too many clients connected.
I haven't yet looked through the codebase of this gem. But since it doesn't happen when I remove it, I'm assuming this is where it comes from.
I'll have a look at it later this week, unless someone does find a fix before that.
Cheers 🌻
DJ handlers, typically being a serialization of an object, can contain sensitive information. The payload of which doesn't seem to be passed through the scrubbing feature.
Perhaps a good solution would be to add a flag to prevent the job from being added to the exception, or adding a hash-key blacklist on the payload before being converted to JSON.
Under the hood, Honeybadger.context saves a hash in a thread local variable. This is better than anything rollbar currently provides, as person data is only available in controllers, and custom data, while providing a means to implement such feature, is rather burdensome to use.
It would be ideal to make the default custom data method extract the data from such a thread local variable, and it should also clean it after both finishing the current request and when Sidekiq finishes a job. (Honeybadger doesn't do the latter.)
I just upgraded to 0.12.12 to get around the "Could not send payload due to it being too large after truncating attempts." issue. MAX_PAYLOAD_SIZE
looks fine in this GitHub repo, but appears to be incorrect in the gem that was downloaded from RubyGems.
[5] pry(main)> Rollbar::MAX_PAYLOAD_SIZE
=> 32768
[6] pry(main)> Rollbar::VERSION
=> "0.12.12"
I opened up rollbar.rb in my Ruby gems directory, and found this:
MAX_PAYLOAD_SIZE = 32 * 1024 #128kb
I ended up setting the version back to 0.12.11, which seems to have the correct value.
If the part of the data associated with an error is too big, it'll be rejected by the Rollbar API. The gem should try to detect this in advance and trim parts of the payload that are likely to be too big.
The documented size limit is 32kb, per the docs. (It's actually currently a bit larger in practice, but 32kb is safer to assume.)
Thanks to @PerfectlyNormal for bringing this up.
Sidekiq 3.0 introduces global error handlers:
https://github.com/mperham/sidekiq/blob/master/Upgrading.md#error-service-providers
Hi,
We're seeing these errors appear now after upgrading from 11.7 to 12.10. We see around 6-7 occurrence per day in production.
I only raise this in case it's helpful for you to know that at least someone if encountering this error relatively frequently, and perhaps it's possible to continue to attempt to reduce the payload, or perhaps the method of reduction could be looked at.
Looking at our log, it appears as though the payload size is due to the stacktrace. It may be beneficial to attempt to prune the stacktrace.
Every report is doubled in production environment. The problem is that with env['action_dispatch.show_detailed_exceptions'] as false exception is reraised during render_exception_without_rollbar, but at this time rollbar already reported the exception, so it sends the report for the seconds time during call_with_rollbar rescue.
Probably, chaging this:
def render_exception_with_rollbar(env, exception)
report_exception_to_rollbar(env, exception)
render_exception_without_rollbar(env, exception)
end
to this:
def render_exception_with_rollbar(env, exception)
render_exception_without_rollbar(env, exception)
report_exception_to_rollbar(env, exception)
end
will fix the problem.
When running bundle, if Rollbar isn't installed yet, Rollbar::VERSION will report nil, and the version 0.0.0 will be used. (At least this is what I think is happening)
In your gemspec, you should really use the true version string and bump it each release. I see what you're doing, but I don't think the constant is the right way...
As glibly said on twitter, it'd be great if there was a way to get our app to give our users an 'Exception Token' that we can eventually search for in ratchet.
Such a token would need to be unique per exception instances (two identical instances, normally grouped in the interface, should be different tokens) for the sake of security.
I'm using rollbar 0.9.3 and zeus 0.13.3. The zeus server fails to start up and I end up with the error below. #25 mentioned adding "require 'rake'" to spec_helper, but this is failing in dev and test environments.
Adding require 'rake' to various points in our app load didn't seem to help, but ultimately I've been able to fix the problem by adding this line to the top of rollbar/rake.rb:
require 'rake/application'
Now obviously that isn't really getting to the bottom of this issue, so I'll keep doing some research into this, but figure there's no harm opening up a ticket in case somebody else comes across the same problem.
zeus c ruby-1.9.2-p320@readingeggs(11:34 am 15-03-13)
/Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/rollbar-0.9.3/lib/rollbar/rake.rb:5:in `alias_method': undefined method `display_error_message' for class `Rake::Application' (NameError)
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/rollbar-0.9.3/lib/rollbar/rake.rb:5:in `<class:Application>'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/rollbar-0.9.3/lib/rollbar/rake.rb:4:in `<module:Rake>'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/rollbar-0.9.3/lib/rollbar/rake.rb:3:in `<top (required)>'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/activesupport-3.2.12/lib/active_support/dependencies.rb:251:in `require'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/activesupport-3.2.12/lib/active_support/dependencies.rb:251:in `block in require'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/activesupport-3.2.12/lib/active_support/dependencies.rb:236:in `load_dependency'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/activesupport-3.2.12/lib/active_support/dependencies.rb:251:in `require'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/rollbar-0.9.3/lib/rollbar.rb:18:in `<top (required)>'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/bundler-1.3.3/lib/bundler/runtime.rb:72:in `require'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/bundler-1.3.3/lib/bundler/runtime.rb:72:in `block (2 levels) in require'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/bundler-1.3.3/lib/bundler/runtime.rb:70:in `each'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/bundler-1.3.3/lib/bundler/runtime.rb:70:in `block in require'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/bundler-1.3.3/lib/bundler/runtime.rb:59:in `each'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/bundler-1.3.3/lib/bundler/runtime.rb:59:in `require'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/bundler-1.3.3/lib/bundler.rb:132:in `require'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus/rails.rb:95:in `default_bundle'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus.rb:166:in `run_action'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus.rb:54:in `block in go'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus/load_tracking.rb:7:in `features_loaded_by'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus.rb:53:in `go'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus.rb:78:in `block (3 levels) in go'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus.rb:78:in `fork'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus.rb:78:in `block (2 levels) in go'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus.rb:73:in `each'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus.rb:73:in `block in go'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus.rb:62:in `loop'
from /Users/brad/.rvm/gems/ruby-1.9.2-p320@readingeggs/gems/zeus-0.13.3/lib/zeus.rb:62:in `go'
From the changes within commit ae36b44 there seems to have been a regression disallowing DJ to requeue jobs after an exception.
In the rescue within the around callback it is effectively returning the results of ::Rollbar.report_exception(e, job)
to DelayedJob as a result of the block eval.
Since the report_exception
call returns 'disabled' or an exception data_hash
which are considered successful responses (non-exception), DJ deletes the job, despite having thrown an exception.
I have a fork containing a fix that simply raises the exception after reporting the exception, but am still testing the impact (seemingly okay so far).
Many examples on the site show {:user => @user}
for extra params to report message on user, how ever it doesn't bind to already existing ones nor creating new ones. I tried to pass :person
as well with no luck, please add support for tracking messages on users
RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.
via e.g.
spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']
Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can image, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.
There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.
I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!
Appendix:
If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies
p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post aobut this project for more information.
With the latest version of rollbar-gem, running rake rollbar:test fails on my my new Rails 4 project.
[Rollbar] Exception while reporting exception to Rollbar: undefined method `inject' for #ActionDispatch::Request::Session::Options:0x000000064936c
I've had a quick look and was able to fix this I think by calling to_hash on the ActionDispatch::Request::Session::Option object that was returned from an earlier call to env['rack.session.options'] in the file request_data_extractor.rb . If it's a hash already it can still be called safely. Seems to work anyway ?
lib/rollbar/request_data_extractor.rb
def rollbar_filtered_params(sensitive_params, params)
94 if params.nil?
95 {}
96 else
97 params.inject({}) do |result, (key, value)|
patched - lib/rollbar/request_data_extractor.rb
def rollbar_filtered_params(sensitive_params, params)
94 if params.nil?
95 {}
96 else
97 params.to_hash.inject({}) do |result, (key, value)|
According to the ruby doc — 1.9.2 doesn't have hostname
method, but 1.9.3 has.
* 2013-04-17 10:00:25 executing `rollbar:deploy'
* executing "cat /deploy/current/REVISION"
servers: ["www"]
[www] executing command
command finished in 167ms
/home/alex/.rvm/gems/ruby-1.9.2-p320/gems/rollbar-0.9.6/lib/rollbar/capistrano.rb:35:in `block (3 levels) in load_into': undefined method `hostname' for #<URI::HTTPS:0x000000034f9d38> (NoMethodError)
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/configuration/execution.rb:138:in `instance_eval'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/configuration/execution.rb:138:in `invoke_task_directly'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/configuration/callbacks.rb:25:in `invoke_task_directly_with_callbacks'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/configuration/execution.rb:89:in `execute_task'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/configuration/execution.rb:101:in `find_and_execute_task'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/callback.rb:38:in `call'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/configuration/callbacks.rb:141:in `block in trigger'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/configuration/callbacks.rb:141:in `each'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/configuration/callbacks.rb:141:in `trigger'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/configuration/callbacks.rb:27:in `invoke_task_directly_with_callbacks'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/configuration/execution.rb:89:in `execute_task'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/configuration/execution.rb:101:in `find_and_execute_task'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/cli/execute.rb:46:in `block in execute_requested_actions'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/cli/execute.rb:45:in `each'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/cli/execute.rb:45:in `execute_requested_actions'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/cli/help.rb:19:in `execute_requested_actions_with_help'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/cli/execute.rb:34:in `execute!'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/lib/capistrano/cli/execute.rb:14:in `execute'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/gems/capistrano-2.14.2/bin/cap:4:in `<top (required)>'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/bin/cap:19:in `load'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/bin/cap:19:in `<main>'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/bin/ruby_noexec_wrapper:14:in `eval'
from /home/alex/.rvm/gems/ruby-1.9.2-p320/bin/ruby_noexec_wrapper:14:in `<main>'
The rollbar railtie depends on ActiveRecord.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.