Polymorphic `has_many` with a `source_type` raise an exception in ActiveHash 4.0

[jpcody]

The following association:

has_many :asset_types, through: :assignments, source: :assignable, source_type: "AssetType"

raises the following exception as a result of #329:

/Users/jpcody/.local/share/mise/installs/ruby/3.3.8/lib/ruby/gems/3.3.0/gems/activerecord-7.1.5.1/lib/active_record/reflection.rb:464:in `compute_class': Polymorphic associations do not support computing the class. (ArgumentError)

          raise ArgumentError, "Polymorphic associations do not support computing the class."
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        from /Users/jpcody/.local/share/mise/installs/ruby/3.3.8/lib/ruby/gems/3.3.0/gems/activerecord-7.1.5.1/lib/active_record/reflection.rb:412:in `klass'
        from /Users/jpcody/.local/share/mise/installs/ruby/3.3.8/lib/ruby/gems/3.3.0/gems/active_hash-4.0.0/lib/associations/associations.rb:14:in `has_many'
        from /Users/jpcody/Projects/CampusOptics/Code/optics-web/app/models/user.rb:38:in `<class:User>'

In our codebase. We follow this association pattern in multiple places, and while I tried to dive in a bit, we're also on the verge of upgrading Rails. For now, I'm going to monkeypatch AH to the old version and see if a newer version of Rails resolves this. But I wanted to go ahead and document the issue in case others run into it. Feel free to close it out if you don't want to have an open issue lying around without a repro case :)

[kbrock]

Thank you for posting.

Are you able to create a test case in active-hash that can recreate this issue?
Preferably one that can be checked in, but at least one that fails would be great.

Do you think it is source_type that is causing the issue?

[kbrock]

@alexgriff are you seeing anything like this?

[alexgriff]

@kbrock
Yep :/

I can repro this in the specs with the following changes to the ephemeral class definitions here

      define_ephemeral_class(:Appointment, ActiveRecord::Base) do
        establish_connection :adapter => "sqlite3", :database => ":memory:"
        connection.create_table :appointments, force: true do |t|
         # make this a polymorphic association
          t.references :providerable, polymorphic: true
          t.references :patient
        end

        extend ActiveHash::Associations::ActiveRecordExtensions
        
       # added belongs_to :physician to keep the api the same for the spec setup object creation
        belongs_to :providerable, polymorphic: true
        belongs_to :physician, -> { where(providerable_type: 'Physician') }, foreign_key: :providerable_id, optional: true, class_name: 'Physician' 
        belongs_to :patient
      end

      define_ephemeral_class(:Patient, ActiveRecord::Base) do
        establish_connection :adapter => "sqlite3", :database => ":memory:"
        connection.create_table :patients, force: true do |t|
        end

        extend ActiveHash::Associations::ActiveRecordExtensions
        
        has_many :appointments
         # this association breaks, like in the reported issue
        has_many :physicians, through: :appointments, source: :providerable, source_type: "Physician"
      end

The issue is calling .klass on a reflection object that represents a polymorphic association, which purposefully raises. Done on this line in the recent changes.

klass = through_klass&.reflect_on_association(source_association_name)&.klass

I feel like there is a solution lurking where if the source_type attribute is given, use that as the klass we want to define the association method on. But would need to poke at it a bit.