opbeat / opbeat_ruby Goto Github PK

I got this problem from using Hashie which is a part of the Grape API framework.

NoMethodError at /alive.json

super: no superclass method `assert_required_properties_set!' for #<Opbeat::ExceptionInterface:0x007f8d52060040>

Ruby    

/Users/olle/.rbenv/versions/2.0.0-p481/lib/ruby/gems/2.0.0/gems/opbeat-0.5.2/lib/opbeat/interfaces.rb
: in 
assert_required_properties_set!

This part of the raven-like ecosystem seems to have solved this problem: https://github.com/getsentry/raven-ruby/pull/191/files

It seems as this line https://github.com/opbeat/opbeat_ruby/blob/master/lib/opbeat/client.rb#L90 fails because location is missing from the response header. An example of the returned response header verifies this:

{
    "connection": "Close",
    "content-length": "57",
    "content-type": "application/json; charset=UTF-8",
    "date": "Sun, 01 Feb 2015 12:47:34 GMT",
    "server": "nginx",
    "x-ratelimit-limit": "250",
    "x-ratelimit-remaining": "249",
    "x-ratelimit-reset": "2015-02-01T12:48:34.112711Z"
}

getsentry/sentry-ruby@2e077fa

Hey,

We're using Devise gem and there is a current_user method in controller, but I cannot see any information about user in Opbeat error page.

In Rails applications, the ENV['RAILS_ENV'] environment variable is not always set, e.g. in development when using Pow as the development server. This causes current_environment to be set to "default" even though the environment is development.

This line could be changed to:

self.current_environment = (defined?(Rails) && Rails.env) || ENV['RACK_ENV'] || 'default'

And it would work in all Rails environments.

Thanks.

Even though the logging event does get submitted to the Opbeat server it tells me otherwise in my console. This happens for all exceptions that is getting sent through the gem.

** [OpbeatRuby] Sending event 160ac3de94b744799e053757941ecf4e to Opbeat
** [OpbeatRuby] Opbeat client connecting to https://opbeat.com
Error capturing or sending exception Error from Opbeat server (202): 

ActiveRecord::RecordNotFound (Couldn't find Profile with id=XXX):
  activerecord (3.2.8) lib/active_record/relation/finder_methods.rb:341:in `find_one'
[...]

After an upgrade to ruby 2 (from 1.9.3) and a bunch of gem upgrades, it seems like all error reporting stopped.

After finding this in the logs:

Error capturing or sending exception no implicit conversion of Pathname into String

I tracked down this pull request from raven:

getsentry/sentry-ruby#113

And while it fixes the initial bug, it looks like a bunch of strings are now Pathnames that are being assumed to be strings:

Error capturing or sending exception undefined method `length' for #<Pathname:

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 imagine, 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 about this project for more information.

The opbeat Capistrano iteration is missing a few flavors of deploy https://github.com/opbeat/opbeat_ruby/blob/master/lib/opbeat/capistrano/capistrano2.rb#L8

See airbrake's implementation: https://github.com/airbrake/airbrake/blob/master/lib/airbrake/capistrano.rb#L64-L66

Alternatively, you can hook into a deeper step of the deploy process itself, perhaps after deploy:start and after deploy:restart

It would be useful for the agent to be able to delegate the actual sending to a background thread. That would enable us to increase the open_timeout and read_timeout without significantly affecting performance.

Thanks for this great gem!

In Ruby, naming conventions are using snake_case for method names, so https://github.com/opbeat/opbeat_ruby/blob/master/lib/opbeat.rb#L94-L102 should be capture_exception and capture_message.

For internals it doesn't matter that much, but I'll be using this in my production code, so I want things to look good and consistent.

Thanks.

We should change the user agent to follow the convention started by the node agent (opbeat-nodejs/version). Today it just looks like: (opbeat/version). Ideally. we'd include the framework too, e.g.: opbeat-ruby/version; rails/4.2 if the rails integration is in effect.

Currently, sending release information from the gem uses the same timeout as sending error/exception information. There's really not a good reason for this, and while it's a good idea to have a low timeout for error/exception info, it can often be a disadvantage and lead to timeouts when sending release info.

The agent should adhere to Rails.application.config.filter_parameters when possible. We already have a way to filter sensitive data, but Rails users will be more familiar with this approach.

It might be worth simplifying the filter mechanism while we're at it. I'm thinking a simple list of regexes that are recursively matched against the hash and the data is removed if the key maches a regex?