Prevent `ActiveSupport::Duration.build(string)` comparison bug

[alexeiemam]

Summary

This change prevents ActiveSupport::Duration instances being created by ActiveSupport::Duration.build(value) unless value is of type ::Numeric (raises TypeError)

This addresses the errant set of behaviours described in #37012 where ActiveSupport::Duration comparisons would fail confusingly or return unexpected results when comparing durations built from strings.

e.g.

## Setup
2.6.3 :001 > small_duration_from_string = ActiveSupport::Duration.build('9')
 => 9.0 seconds 
2.6.3 :002 > large_duration_from_string = ActiveSupport::Duration.build('100000000000000')
 => 3168873 years, 10 months, 6 days, 8 hours, 4 minutes, and 4.0 seconds 
2.6.3 :003 > small_duration_from_int = ActiveSupport::Duration.build(9)
 => 9.0 seconds 
## Comparison
2.6.3 :004 > large_duration_from_string > small_duration_from_string
 => false 
2.6.3 :005 > small_duration_from_string == small_duration_from_int
 => false 
2.6.3 :006 > small_duration_from_int < large_duration_from_string
Traceback (most recent call last):
        1: from (irb):6
ArgumentError (comparison of ActiveSupport::Duration::Scalar with ActiveSupport::Duration failed)
2.6.3 :007 > large_duration_from_string > small_duration_from_int
Traceback (most recent call last):
        2: from (irb):7
        1: from (irb):7:in `rescue in irb_binding'
ArgumentError (comparison of String with ActiveSupport::Duration failed)

Other Information

[alexeiemam]

@eileencodes @tenderlove @pixeltrix any blocking issues problems with this Pull Request?

[pixeltrix]

@alexeiemam my preference would be certainly for build not having to deal with string/numeric conversion. This is based on the fact that we don't support doing things like '30'.seconds so it doesn't make sense to accept strings in build.

In fact had I realised that build wasn't marked as :nodoc: I would've asked for it in the original PR that added the method, however that ship has sailed so lets not overload this method with too much responsibility, thanks.

[alexeiemam]

@pixeltrix: Would it be appropriate, then, to raise a type error on initialize if the passed value is not Numeric?
To remove the possibility of creating a Duration object that looks like a duck, swims like a duck and quacks like a duck but barks like a fish.

[pixeltrix]

@pixeltrix: Would it be appropriate, then, to raise a type error on initialize if the passed value is not Numeric?
To remove the possibility of creating a Duration object that looks like a duck, swims like a duck and quacks like a duck but barks like a fish.

It's arguable that we should deprecate it first but given the fact that it's broken anyway and either gives a result based on comparing two strings using > or blows up with ArgumentError I think we can go straight to raising a TypeError with a appropriate message like:

>> ActiveSupport::Duration.build('1')
TypeError (can't build an ActiveSupport::Duration from a String)

[alexeiemam]

@pixeltrix have modified the code, now raises error on .build rather than perform conversion.

[eugeneius]

These tests could be clearer and shorter with assert_raises:

    error = assert_raises(TypeError) do
      ActiveSupport::Duration.build("9")
    end

    assert_equal "can't build an `ActiveSupport::Duration` from a `String`", error.message

[alexeiemam]

@eugeneius: Updated in f8dbaf0

[pixeltrix]

Can you also add an entry to the Active Support CHANGELOG.md and squash it down to a single commit so that we don't have the redundant changes in the Rails commit history, thanks.

[pixeltrix]

Can you remove the backticks from the message please - the other message doesn't have them and core Ruby exception messages don't so I'd rather stick to that pattern (though I accept there are places elsewhere in Rails they are added).

[alexeiemam]

@pixeltrix: Changed in 94fa3e8

[alexeiemam]

@pixeltrix: squashed into b8b7e85

[eugeneius]

These assertions are backwards; the expected value should be passed first. See a46b2f8.

[alexeiemam]

@eugeneius: changed in 94fa3e8

[alexeiemam]

@eugeneius: Squashed into b8b7e85

[alexeiemam]

@pixeltrix @eugeneius
Rebased against current HEAD of master for avoidance of merge conflicts.

[pixeltrix]

@alexeiemam thanks for your contribution! 👍