bugfix: sentry crashes when exeception message is an array.

[xiaoronglv]

Problem

when the exception message is not a string, the sentry will crash and sentry SDK will cause main application to crash.

Here is an example of to crash sentry.

class CustomError < StandardError
  attr_accessor :message

  def initialize(message)
    @message = message
  end
end


e = CustomError.new(["dasdf", "asfd"])


Sentry.capture_exception e

Then, you will get this error.

shared/bundle/ruby/3.0.0/gems/sentry-ruby-5.4.1/lib/sentry/interfaces/single_exception.rb:18:in `initialize': undefined method `byteslice' for ["dasdf", "asfd"]:Array (NoMethodError)

Usually, the developer should use a standard string as the exception message, but Sentry can't assume all developers follow this convention and the exception message is a string.

Sometimes it's a hash or array.

Solution

if the exception message is not a string, the byteslice should not be called.

[st0012]

Which Ruby version are you using? In the versions of Ruby I tested (as early as Ruby 2.4), Exception#message only returns String even if it's initialized with non-string objects:

irb(main):001:0> StandardError.new(message: [1, 2]).message
=> "{:message=>[1, 2]}"
irb(main):003:0* RUBY_VERSION
=> "2.4.10"

Also, when facing an issue like this, please file a proper issue report with more information first.

[xiaoronglv]

Hi @st0012 ,

I have updated the script to reproduce this issue.

class CustomError < StandardError
  attr_accessor :message

  def initialize(message)
    @message = message
  end
end


e = CustomError.new(["dasdf", "asfd"])


Sentry.capture_exception e

Then, you will get this error.

/var/www/shared/bundle/ruby/3.0.0/gems/sentry-ruby-5.4.1/lib/sentry/interfaces/single_exception.rb:18:in `initialize': undefined method `byteslice' for ["dasdf", "asfd"]:Array (NoMethodError)

[st0012]

It's the author of CustomError's responsibility to make sure the message override maintains the same behavior. So in this case, the checkr gem should maintain that compatibility.

[xiaoronglv]

I agree with you. Ruby exception usually return a string as the value of the message. and it's the CustomError' responsibility to follow the ruby best practice.

But the reality is another consideration. Each ruby project usually imports dozens of libraries. For the frontend project, it could be 100+ npm libraries. Usually, the developers never go through the source code of libraries. I believe there are tons of errors that have not been well-defined.

As a customer of the sentry, I would appreciate it if the sentry could raise awareness to the clients even though they are not well defined.

[st0012]

In the checkr's case, it overrides an API that it shouldn't and probably don't need to override. And in my experience this doesn't happen often. Also, the root cause can be easily addressed.

It's not like we expect users to follow all Ruby best practices to use the SDK. The question here imo is "whether the SDK should prepare for unconventional patches from 3rd-party code". And if the answer is yes, then our codebase will need to handle all the edge cases that could be produced out of our control, which isn't practical.