Hi @PhilCoggins Thanks for raising this issue. Would you mind providing an example so we can reproduce it?

Thanks @estolfo, here is a sample app with instructions:

https://github.com/PhilCoggins/elasticsearch-sti-fail

LMK if you have any issues running. I tried to do this in a single script file but ActiveSupport::Reloader.reload would not trigger the error for some reason.

I'm also hitting this, will use the initializer patches for now.

Looking at the code, I wonder if it makes sense to use the before_class_unload hook to empty the @models array as well.

@darkhelmet You could, though that's already occurring in the Elasticsearch::Model::Registry#add monkey patch (we remove a model if there's already one there with the same constant name).

Also want to point out that the initializer is wrapped in an environment check since I only need this on dev, not sure how it would behave in prod.

Yeah, this is what I ended up with in my initializer.

if Rails.env.development?
  Rails.application.reloader.before_class_unload do
    Elasticsearch::Model::Registry.remove_instance_variable(:@instance)
    Elasticsearch::Model::Adapter::Multiple::Records.remove_class_variable(:@@__types)
  end
end

Is there any movement on a gem fix for this? I just ran into this and its a major issue. It only happens for me in Rails5, though which we are currently upgrading to. I've never encountered this in Rails4.

@surjay I will look into it and have an update soon!

@PhilCoggins I'm having trouble reproducing this using the example app you provided. I followed the steps in the README. Is there anything I'm missing below?

2.5.1 :001 > require_dependency 'animal'
 => true 
2.5.1 :002 > Elasticsearch::Model.search("Fluffy")
 => #<Elasticsearch::Model::Response::Response:0x00007f8018591588 @klass=#<Elasticsearch::Model::Multimodel:0x00007f80185932c0 @models=[Animal (call 'Animal.connection' to establish a connection)]>, @search=#<Elasticsearch::Model::Searching::SearchRequest:0x00007f80185930b8 @klass=#<Elasticsearch::Model::Multimodel:0x00007f80185932c0 @models=[Animal (call 'Animal.connection' to establish a connection)]>, @options={}, @definition={:index=>["animals"], :type=>["_doc"], :q=>"Fluffy"}>> 
2.5.1 :004 > reload!
Reloading...
 => true 
2.5.1 :005 > Elasticsearch::Model.search("Fluffy")
 => #<Elasticsearch::Model::Response::Response:0x00007f801da14380 @klass=#<Elasticsearch::Model::Multimodel:0x00007f801da146f0 @models=[Animal (call 'Animal.connection' to establish a connection)]>, @search=#<Elasticsearch::Model::Searching::SearchRequest:0x00007f801da14600 @klass=#<Elasticsearch::Model::Multimodel:0x00007f801da146f0 @models=[Animal (call 'Animal.connection' to establish a connection)]>, @options={}, @definition={:index=>["animals"], :type=>["_doc"], :q=>"Fluffy"}>> 
2.5.1 :006 > Elasticsearch::Model::Registry.all
 => [Animal (call 'Animal.connection' to establish a connection)] 
2.5.1 :007 > reload!
Reloading...
 => true 
2.5.1 :008 > Elasticsearch::Model::Registry.all
 => [Animal (call 'Animal.connection' to establish a connection)] 

@estolfo thanks for reaching back out.

I have updated the instructions in the repo. Also make sure you run the setup instructions at the top (rails db:migrate and rails runner script.rb)

@PhilCoggins I've opened this pull request but I get a (ActiveRecord::SubclassNotFound) error when I test it with your example app. Maybe there's something else that needs to change in the example app to fully test the changes. I'll work on adding tests but I wanted to get the PR up asap so you could take a look and let me know what you think.

I would consider the ActiveRecord::SubclassNotFound a derivative of the core issue.

Somehow, when a klass is first added to the @models array, it initially contains no descendants, but subsequently performing a search the descendant is added.

When code is reloaded, however, the klass is added to the @models array, and a search is performed, the descendants don't get added.

Using your branch of elasticsearch-model on my test project:

irb(main):001:0> require_dependency 'animal'
=> true
# Open connection
irb(main):002:0> Animal.connection
# Animal is in registry
irb(main):003:0> Elasticsearch::Model::Registry.all
=> [Animal(id: integer, name: text, type: text)]
# The model contains no descendants (ActiveRecord has not yet loaded this class)
irb(main):004:0> Elasticsearch::Model::Registry.all[0].descendants
=> []
irb(main):005:0> Elasticsearch::Model.search("Fluffy").records.to_a
=> [#<Dog id: 4, name: "Fluffy", type: "Dog">]
# Descendants now show up
irb(main):006:0> Elasticsearch::Model::Registry.all[0].descendants
=> [Dog(id: integer, name: text, type: text)]
irb(main):007:0> reload!
Reloading...
=> true
# Code reloaded, registry updated with new class, no descendants
irb(main):008:0> Elasticsearch::Model::Registry.all[0].descendants
=> []
# Blows up
irb(main):009:0> Elasticsearch::Model.search("Fluffy").records.to_a
Traceback (most recent call last):
        1: from (irb):9
ActiveRecord::SubclassNotFound (The single-table inheritance mechanism failed to locate the subclass: 'Dog'. This error is raised because the column 'type' is reserved for storing the class in case of inheritance. Please rename this column if you didn't intend it to be used for storing the inheritance class or overwrite Animal.inheritance_column to use another column for that information.)

I hope this helps.

@PhilCoggins thanks for the extra info, I'll keep investigating.

I want to give an update on this: I've been looking into the cause of the inherited class not being autoloaded after reload! is called and in the process, I've realized a big issue with using STI and Elasticsearch 7. Essentially, the feature was making use of the document type in the index but types are deprecated as of Elasticsearch 7. See here for more info on that.

That means we'll have to figure out another mechanism for supporting STI with Elasticsearch 7, as we can't rely on the automatic population of _type field based on the model name.

I'll have an update soon, thanks again for your patience.

@PhilCoggins I think one of the ways to support STI going forward with the removal of types in Elasticsearch would be to add an artificial type field to each document if inheritance is detected. I did this in the past with Mongoid. What do you think about that approach? For example:

class Animal < ApplicationRecord
  include Elasticasearch::Model
end

class Dog < Animal
end

The name, _inheritance_type is inspired by rail's inheritance_column

d = Dog.create(name: 'Fluffy')
# => { name: 'Fluffy', _inheritance_type: 'dog' }

Mongoid does something similiar in automatically adding a _type field in the document. It detects when a class is inherited and adds the _type field to a query if necessary.

One drawback of this approach is that an extra field is added to the document and that field has to be in the mapping and added to queries.

There are other ways to implement this but they are more manual and require user intervention.

Not only in elasticsearch, I am also getting this error when using with active admin. Attached the screenshot.
This should be fixed.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Update: still seeing this in 7.2.1 Rails 5.2. After reloading the Elasticsearch::Model::Registry.all[0].descendants is blank, so the ActiveRecord::SubclassNotFound is being thrown.

What is interesting is that I am putting my STI subclasses in the same index so should it not get instantiated using the base class?

Following the Dog < Animal example from above...

If all Dogs are indexed in the animals index, should it not instantiate them with Animal.where(id: [...]). It seems like Rails should take care of this with nothing else required here but yet the SubclasNotFound occurs.

@stalebot, please reopen - closing active issues does not make them go away.