When someone forcefully replaces a collection in a managed entity (this.myCollection = <some other collection), there are specific steps that ORM needs to follow because it lost the metadata contained in the collection it originally injected.

When doing so, ORM send a PostCollectionRecreateEvent and we receive that event in our listener.

It turns out that when Hibernate ORM sends a PostCollectionRecreateEvent, the collection role is not available when calling event.getCollection().getRole() (it's null), even though the collection has obviously been created by ORM: in my case I used an ArrayList in the test, and found a PersistentBag in the event.

As a result, Hibernate Search doesn't know which collection is being modified, and it ends up triggering reindexing "just in case", because it can't possibly know if the change will impact the indexed version of the owning entity.

We should investigate, see if it is a bug in ORM that can be fixed, or if it is something that cannot change for some reason.

I am adding tests as part of HSEARCH-3199 In Progress and will mark those tests with @TestForIssue with the key of this ticket.