Name collision of detailed_message method between Exception classes in aws-sdk-neptunedata gem and Ruby 3.2+ #3383

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

• Select this option if this issue appears to be a regression.

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+