If you notice that the data in your Algolia index doesn't match the data in Magento, it could be due to one of the following causes:
- An error occurred during the indexing process. We have a guide on investigating logs to troubleshoot errors here.
- If the Indexing Queue is enabled, there could be a problem with the processing of the queue. Read more about this here.
- The product or category being indexed has a particular status preventing it from being indexed. The requirements for a product or category to be indexed can be found on our indexing page.
Debugging missing products/categories
If your data meets the requirements listed on the indexing page, but is still not appearing in your Index, read on.
Firstly, go into the Magento back-office and find the product or category that's missing. Then save the item without changing anything. This should trigger the Magento save event, and start an indexing job to send the data to our servers. This can also be tried with the Indexing Queue turned off.
Next, head to our Dashboard. Here, you can check if the product or category was updated. Navigate to the index, look up the product/category and check the algoliaLastUpdateAtCET attribute. This attribute contains the date and time the record was updated (Central European Time).
If the products is still out of sync, check the logs on our Dashboard. The logs can be found by navigating to Monitoring > Logs, and inspecting the Latest Operations panel. Reindexing triggers a POST request that should appear at the top of the list. The url should look something like /1/indexes/[INDEX_NAME]/batch.
By clicking the link, the request details will be displayed. The Request Body tab should contain an AddObject action with all the entity’s attributes. If the attributes are there, it means the record was successfully sent to our servers.
If the attributes are not updated, and the algoliaLastUpdateAtCET attribute in the index’s object is not updated, the SKU Reindexing Form should be used. This form will give you feedback on why the product is not updated.
Third-party extensions
Our extension relies on Magento’s plug-in system. By leveraging this system, we apply our logic on the following Magento classes:
Magento\Catalog\Model\ResourceModel\ProductMagento\Catalog\Model\Product\ActionMagento\CatalogInventory\Model\ResourceModel\Stock\ItemMagento\Catalog\Model\ResourceModel\CategoryMagento\Catalog\Model\Category\Action
Any third-party extension that updates resources without triggering Magento’s save events on the classes listed above, will break the real-time updating of the catalog. To fix this, the reindexing has to be triggered manually.
Updates are not propagated to Algolia
In cases where the data in our Dashboard has unexpected values, check the attributes specific to the store view or website. Our extension respects settings set at the store view and website level, and this may override the default settings. To check if this is the case, change the view to show the store view or website setting by using the store switch (found in the top-left corner).
Investigate the logs
First of all, it’s important to figure out if your indexing process generates errors or not. Sometimes, since the process can be asynchronous, errors can happen without you being made aware of them.
During the asynchronous indexing process, our extension generates temporary indices, suffixed by _tmp. For example, if the main product index is magento_products_default, the extension will generate an index named magento_products_default_tmp.
The temporary indices are created to do an atomic reindex to prevent production indices from being corrupted.
Because the temporary index is only swapped after the whole process completed successfully, it’s easy to discover if an error happened in the process. If an error happened, the temporary index will often still exist. To check this, visit our Dashboard and check any indices that end with the _tmp suffix that haven’t been updated in a while. If this is the case, the process probably errored at some point.
All errors are logged by default in Magento. The var/log folder in the Magento installation contains two log files:
system.logexception.log
If you want to see if anything gets logged during the indexing process, run the following command from the terminal (from the root folder of the Magento installation) before re-running the indexing process again:
Shell
$ tail -f var/log/system.log v
The logs will provide the exact error messages for the errors that occurred. This message makes it possible to pinpoint the source of the issue.
We also provide the options of more detailed logging during the indexing process. Read our logging and debugging page to learn more about this.
The queue may be stuck
If the data in your index is not up-to-date, it could be possible that the Indexing Queue is stuck. Follow these steps to make sure the queue is not stuck.
The Indexing Queue relies on one of Magento’s indexers, added by our extension; the algolia_queue_runner.
To learn more about Magento indexers, read the official Magento documentation.
First of all, make sure the Magento indexer is “ready”. This can be done by running the following command in the command line:
Shell
$ php bin/magento indexer:status algolia_queue_runner
Shell
$ php bin/magento indexer:reset algolia_queue_runner
Monitoring the queue
Since version 1.8 of our extension, a screen is added in the Magento administration. This screen can be found by navigating to Stores > Algolia Search > Indexing Queue. This page contains a grid, displaying the contents of the indexing queue. It provides an easy way to monitor the amount of operations the queue needs to perform.
The operations listed can also be viewed in detail by clicking the ‘view’ link. Any error occurring during the job will be logged in the Error Log attribute.
At the top of the page, a recommendations section will be shown, to help you configure and optimize the queue in the best way possible.
If the Indexing Queue is performing normally, the amount of jobs on the page should decrease every 5 minutes (don’t forget to refresh). When the amount of operations doesn’t decrease, please make sure the queue is set up properly.
Finally, since version 1.8 of our extension, any failing operation that reached the maximum amount of retries will be archived in the algoliasearch_queue_archive table. This can be another useful place to check for error logs, since we automatically store the last encountered error along with the job.