PHPackages aligent/magento2-indexer-fix - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. aligent/magento2-indexer-fix ActiveMagento2-module aligent/magento2-indexer-fix ============================ Fix to core Magento scheduled indexing to avoid inconsistent index data 1.0.1(3y ago)1022.1k↓38.9%3GPL-3.0-onlyPHPPHP ^8.1 Since Dec 8Pushed 3y ago8 watchersCompare [ Source](https://github.com/aligent/magento2-indexer-fix)[ Packagist](https://packagist.org/packages/aligent/magento2-indexer-fix)[ RSS](/packages/aligent-magento2-indexer-fix/feed)WikiDiscussions main Synced 1mo ago READMEChangelog (2)Dependencies (2)Versions (4)Used By (0) Magento 2 Scheduled Indexing Fix ================================ [](#magento-2-scheduled-indexing-fix) This module is designed to fix a common issue around the scheduled "mview" indexing within Magento 2. Background ---------- [](#background) When indexers are set to update by schedule, the scenario is as follows: - Each indexer has a corresponding changelog database table. - Each indexer subscribes to a number of database tables - when a change is made in a subscribed table, a record is added to the changelog table for the indexer. Additionally, some indexers use the data created by another indexer. For example, the `catalogsearch_fulltext` indexer may use indexed category and price data. Indexed data is updated via the `indexer_update_all_views` cron job. This job loops through all scheduled indexers and updates its data based on the latest changelog record for each one. Issue ----- [](#issue) When `indexer_update_all_views` runs, it will get the changelog information for a single indexer, process it, and then move on to the next one. Consider the following scenario: 1. The `mview_state` table has `version_id` of `100` for both `catalog_product_price` and `catalogsearch_fulltext` records. 2. Both `catalog_product_price_cl` and `catalogsearch_fulltext_cl` changelog tables are also at version `100`. 3. The prices of 10 products are updated 1. This adds 10 records to `catalog_product_price_cl` and `catalogsearch_fulltext_cl` 2. Latest version in the changelog tables is now `110` 4. `indexer_update_all_views` begins, and starts to process the `catalog_product_price` indexer. 1. It determines that it needs to process changelog records `101-110` 5. Before the price indexer has finished processing, 10 more product prices are updated. 1. 10 more recrds are added to `catalog_product_price_cl` and `catalogsearch_fulltext_cl` 2. Latest version in the changelog tables is now `120` 6. `indexer_update_all_views` finishes processing the price indexer, and moves on to `catalogsearch_fulltext` 1. It determines that it needs to process changelog records `101-120` 7. `indexer_update_all_views` completes 8. The next run of `indexer_update_all_views` processes records `111-120` for the price indexer. After this, everything *seems* to be up to date - this is not the case. Since the `catalogsearch_fulltext` indexer uses indexed price data, when it processed records `101-120`, it did not have up-to-date data for `111-120`, as these had not yet been processed by the price indexer. The products corresponding to these last 10 changelog records will not be updated by the `catalogsearch_fulltext` indexer again until either: - The index is invalidated and a full re-index is performed. - The product gets updated again in some way. Fix --- [](#fix) In order to avoid timing issues relating to updates happening at the same time as index processing, this module does the following: - Before `indexer_update_all_views` begins processing, a snapshot of all changelog tables is taken, recording the (at the time) latest version number. - An around plugin is added to the `ChangelogInterface->getVersion` function, so that the snapshot version is returned - If a snapshot does not exist, it is looked up from the database as per normal functionality By doing this, any new changelog records that are created while the job is running will be ignored, and instead processed by the next run. Installation ------------ [](#installation) To install this module, the following commands can be run: ``` composer require aligent/magento2-indexer-fix bin/magento module:enable Aligent_IndexerFix bin/magento setup:upgrade ``` ### Health Score 35 — LowBetter than 80% of packages Maintenance20 Infrequent updates — may be unmaintained Popularity35 Limited adoption so far Community14 Small or concentrated contributor base Maturity57 Maturing project, gaining track record Bus Factor1 Top contributor holds 83.3% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~43 days Total 2 Last Release 1211d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/d2562970d9b77564454ead1236c1db5ddedb44198bb00925b614418c4105f541?d=identicon)[aligent](/maintainers/aligent) --- Top Contributors [![aligent-lturner](https://avatars.githubusercontent.com/u/40189797?v=4)](https://github.com/aligent-lturner "aligent-lturner (5 commits)")[![ktharindu](https://avatars.githubusercontent.com/u/5354794?v=4)](https://github.com/ktharindu "ktharindu (1 commits)") --- Tags magentomagento2 ### Embed Badge ![Health badge](/badges/aligent-magento2-indexer-fix/health.svg) ``` [![Health](https://phpackages.com/badges/aligent-magento2-indexer-fix/health.svg)](https://phpackages.com/packages/aligent-magento2-indexer-fix) ``` ### Alternatives [fastly/magento2 Fastly CDN Module for Magento 2.4.x 1564.2M1](/packages/fastly-magento2)[mage-os/module-automatic-translation Automatic AI content translation for Mage-OS. 277.1k](/packages/mage-os-module-automatic-translation)[zepgram/module-rest Technical module to industrialize API REST call with dependency injection pattern using Guzzle library 1326.2k](/packages/zepgram-module-rest)[graycore/magento2-graphql-introspection-cache 1015.2k](/packages/graycore-magento2-graphql-introspection-cache)[mage-os/mageos-common-async-events Send REST requests to external endpoints asynchronously. This module implements the most common events like order creation and customer change. 147.7k2](/packages/mage-os-mageos-common-async-events)[mage-os/module-inventory-reservations-grid Add a grid with the list of inventory reservations. 126.8k](/packages/mage-os-module-inventory-reservations-grid) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)