Describe the bug
In Ruby 3.2, Exception#full_message was updated to internally call detailed_message(highlight:) (a Ruby built-in method) passing a keyword argument (code here). All 34 error classes in aws-sdk-neptunedata define a detailed_message (code here) to expose the API-level detailed_message field (consequently, that method definition becomes a method override when using ruby 3.2+), but none accepted the highlight: keyword, causing an ArgumentError whenever Ruby or tooling calls full_message on these exceptions.
A real example of that error happening is in OpenTelemetry SDK's span.record_exception(e) (code here), which calls e.full_message(highlight: false, order: :top) (code here) to capture the stacktrace. This silently breaks tracing and any instrumentation that records exceptions on spans since raises the error.
As a temporary fix, I've overridden the detailed_message in all error classes in aws-sdk-neptunedata as monkey patch to also accept right parameters, so it avoids the exception being raised when calling the detailed_message, so my code can work properly.
Regression Issue
Expected Behavior
A way to make the exceptions classes from API work well with Ruby 3.2+ updates.
Current Behavior
There is a name collision of method detailed_message between error classes in aws-sdk-neptunedata API and Ruby 3.2+ built-in base exception class, so it raises an ArgumentError exception when the method is called with parameters.
Reproduction Steps
Instantiate an exception/error class from aws-sdk-neptunedata, call the method full_message (buil-in in ruby 3.2+), it'll raise an ArgumentError.
Possible Solution
Change the method name in the API from detailed_message to any other. 🤷 It'll require a new major version of the gem. =/
At least it'll keep the API behavior consistent and keep the ruby exception behavior as it is.
Overrride explicit the detailed_message with a a specific behavior for the API. It'll keep backward compatibilities (a minor/patch bump), but will change the default behavior of the ruby exception message, anyway a good documentation could make it ok for users.
Well, looking forward to know how you folks will decide to resolve that issue. =)
Additional Information/Context
No response
Gem name ('aws-sdk', 'aws-sdk-resources' or service gems like 'aws-sdk-s3') and its version
aws-sdk-neptunedata in any version with detailed_message method defined in error classes
Environment details (Version of Ruby, OS environment)
Ruby 3.2+
Describe the bug
In Ruby 3.2,
Exception#full_messagewas updated to internally calldetailed_message(highlight:)(a Ruby built-in method) passing a keyword argument (code here). All 34 error classes inaws-sdk-neptunedatadefine adetailed_message(code here) to expose the API-leveldetailed_messagefield (consequently, that method definition becomes a method override when using ruby 3.2+), but none accepted thehighlight:keyword, causing anArgumentErrorwhenever Ruby or tooling callsfull_messageon these exceptions.A real example of that error happening is in OpenTelemetry SDK's
span.record_exception(e)(code here), which callse.full_message(highlight: false, order: :top)(code here) to capture the stacktrace. This silently breaks tracing and any instrumentation that records exceptions on spans since raises the error.As a temporary fix, I've overridden the
detailed_messagein all error classes inaws-sdk-neptunedataas monkey patch to also accept right parameters, so it avoids the exception being raised when calling thedetailed_message, so my code can work properly.Regression Issue
Expected Behavior
A way to make the exceptions classes from API work well with Ruby 3.2+ updates.
Current Behavior
There is a name collision of method
detailed_messagebetween error classes inaws-sdk-neptunedataAPI and Ruby 3.2+ built-in base exception class, so it raises an ArgumentError exception when the method is called with parameters.Reproduction Steps
Instantiate an exception/error class from
aws-sdk-neptunedata, call the methodfull_message(buil-in in ruby 3.2+), it'll raise an ArgumentError.Possible Solution
Change the method name in the API from
detailed_messageto any other. 🤷 It'll require a new major version of the gem. =/At least it'll keep the API behavior consistent and keep the ruby exception behavior as it is.
Overrride explicit the
detailed_messagewith a a specific behavior for the API. It'll keep backward compatibilities (a minor/patch bump), but will change the default behavior of the ruby exception message, anyway a good documentation could make it ok for users.Well, looking forward to know how you folks will decide to resolve that issue. =)
Additional Information/Context
No response
Gem name ('aws-sdk', 'aws-sdk-resources' or service gems like 'aws-sdk-s3') and its version
aws-sdk-neptunedata in any version with detailed_message method defined in error classes
Environment details (Version of Ruby, OS environment)
Ruby 3.2+