save() happens to be different if the id generation uses column id. In this case, ORM must persist the entity right away because save() returns the identifier. In this case, the entity is stored and the index operation is in the queue. Clearing the indexing queue in this case will make the index inconsistent with the database (unless the DB is rolled backed).

Ahh, that was the missing piece. The id generation type. I knew I must be missing something. If I switch the generation type I indeed get only a single PostInsertEvent for the seconf Foo instance. So things actually work as expected. If Session#clear has any effects on the current session this will be reflected in the events received in FullTextIndexEventListener. No need to clear the indexing queue. The problem is that there might be more to save/persist/clear than meets the eye. For example the id generation strategy plays a big role.

So in some ways, clear() is fine by not clearing the queue, or maybe it should force a queue flush before actually clearing.

In this light I think things work as expected and HSEARCH-1270 should probably be rejected

All that to say that I am not sure we need clearIndexingQueue()

Not me either.