Designing a Safe Magento Admin Reindex Queue

Magento already exposes indexer state in System > Tools > Index Management. The missing operational step is a safe way for an authorised administrator to request selected reindex or reset work without holding an HTTP request open or requiring shell access.

A synchronous controller is attractive because it is small, but it couples page lifetime, PHP limits and browser behaviour to work that may take minutes. It also becomes difficult to explain what happens when two administrators choose the same indexer, one indexer fails, or no consumer is running. The queue design has to answer those questions before the button is useful.

The implementation uses Magento Bulk Operations to represent user-visible work, Message Queue to execute it outside the request, ACL to authorize the action, LockManager to protect scheduling, cron history and the consumer lock as health signals, and native indexer APIs for Reindex and Reset.

That division matters. The module does not introduce a second job table, a custom process supervisor or a parallel indexer abstraction. Magento remains responsible for indexer state and message consumption, while the extension contributes request validation, operation ownership, deduplication and progress presentation.

A read-then-publish check is not enough. Two Admin requests can both observe no open operation and publish the same indexer before either request writes the state the other one expects. The duplicate check and publish decision therefore run inside one Magento LockManager lock.

For a mixed selection, the scheduler can reuse existing bulk UUIDs for indexers already pending or running and create a new bulk only for the remaining indexers. The progress view aggregates those UUIDs so the administrator still sees each selected indexer once.

A queued operation is not the same as a running operation. The Admin should warn before scheduling when there is no evidence that the configured consumer path is working. Useful signals include Magento's consumer lock, recent successful or running consumers_runner cron history, the age of pending module operations, and the last operation start time.

No single signal is perfect. A continuously running consumer started without the expected lock option may be healthy while idle but invisible to the lock check. Recent successful processing can still count as evidence. The warning should describe uncertainty, allow an intentional queue, and never start an operating-system process from the Admin request.

Bulk progress is restricted to the administrator who created the work. That prevents an otherwise authorised user from reading another administrator's operation detail merely by learning a UUID. The UI receives safe summaries, while full exceptions remain in Magento logs with the indexer identifier and operation context.

The consumer processes selected indexers so one failure can be recorded without discarding later work. A complete, running, skipped, failed and remaining count is more useful than a single percentage because it explains partial success and makes support diagnosis possible.

The happy path proves very little for background work. The release matrix should include an absent consumer, two near-simultaneous requests for the same indexer, a mixed selection with existing work, an indexer that throws, a user without the dedicated ACL, a user trying to read another owner's progress, and a page closed immediately after scheduling.

Installation also matters. The queue destination is registered through Magento setup, so skipping setup:upgrade can leave a request that appears scheduled but never reaches a valid consumer path.

Verify the request, queue, consumer, Magento indexer state and visible Admin result as one workflow. A green controller response is not enough.