What could cause an index wipeout?

If you are using  the v3 Java API Client  and replaceAllObjects, please upgrade to Java v4, as v3 has a bug impacting this. 

If all the records and settings in your index disappear, you may have a bug in your indexing implementation. Here are the most common causes:

• Overriding setSettings operations.
• An issue with the reindexing functionality.

Overriding setSettings operations

To investigate this you can check your logs for setSettings operations or copySettings operations and look for overwrites. You can access your logs via the API or the Dashboard, by going to API Monitoring > Search API Logs - https://dashboard.algolia.com/apps/[APP ID]/monitoring/logs

An issue with the reindexing functionality

A proper reindexing system should work as follows:

1. Copy settings, synonyms, and rules from your original index to a temporary index.
2. Add your new records to the temporary index.
3. Replace your original index with the temporary index.

An issue with the reindexing logic may alter this cycle and cause a replacement of the original index (e.g. with an empty temporary index).

If you don't wait for your operations to finish building by receiving a "published" response from your wait request, a race condition can be triggered. A request that was sent after your copy operation (like a batch request) can be built before your copy operation finishes building. Because the batch request writes to an empty index, this ultimately results in an index with only the default settings and config overwriting your main index. 

Duplicating reindexing operations can also cause problems. This issue can happen when two reindexing jobs run at the same time and use the same temporary index name.

1. Job A and Job B both create a temporary index called MyTempIndex by copying settings from the main index.
2. Both jobs start adding records to this same temporary index.
3. Job A finishes first and renames MyTempIndex to MyPermanentIndex.
   • This replaces the original index with the fully built one.
   • The temporary index (MyTempIndex) is deleted as part of the rename.
4. Job B is still running, but its temporary index no longer exists.
   • When it continues adding records, it recreates MyTempIndex from scratch, this time without the original settings.
5. Job B then renames its new MyTempIndex to MyPermanentIndex, overwriting the correct index created by Job A.
   • The result is a broken or incomplete index, missing settings and/or records.

Running multiple reindexing jobs in parallel with the same temporary index name can cause one job to overwrite the work of another, leading to data loss or incorrect configurations.