What happened in our particular use case is that we deployed an application with one index configuration, then realized we needed to change that configuration (by specifying non-default analyzers for certain fields). It was our understanding at the time (possibly mistaken) that simply dropping the index and then requesting a re-indexing of the data would recreate the index anew. Or, that restarting the application would also solve the problem (restarting does work but since we have a clustered application and dynamic additions to the search, it is tricky to do with auto-index creation enabled, since by the time one app starts up and initializes Hibernate Search, another still-running app instance may have already auto-created the “bad” index)

I guess what makes this situation particular for us is that we are using Hibernate Search on Elasticsearch specifically just as a fast linguistic index for values which are actually stored elsewhere (in a regular relational database). So for us, dropping the index or the values in the index is basically harmless – the optimized search system just doesn’t work until it’s rebuilt, but no actual data has been lost. I can certainly understand that an application using Elasticsearch as its actual real data store would not expect this situation at all; it is absolutely a fatal error condition.