This is split from T252764: Automatic renaming by Fuzzybot broken to focus on the underlying issue. It is likely that our rename jobs trigger a rare code path due to them causing a lot of deferred updates.
The trace is:
- require_once
- RunJobs->execute
- JobRunner->run
- JobRunner->executeJob
- JobRunner->doExecuteJob
- MessageUpdateJob->run
- MessageUpdateJob->handleRename
- MovePage->move
- MovePage->moveUnsafe
- MovePage->moveToInternal
- ManualLogEntry->publish
- DeferredUpdates::addCallableUpdate
- DeferredUpdates::addUpdate
- DeferredUpdates::tryOpportunisticExecute [loop starts]
- DeferredUpdates::enqueueUpdates
- JobQueueGroup->push [1]
- JobQueue->push
- JobQueue->batchPush
- JobQueueDB->doBatchPush
- Wikimedia\Rdbms\DBConnRef->onTransactionPreCommitOrIdle
- Wikimedia\Rdbms\DBConnRef->__call
- Wikimedia\Rdbms\Database->onTransactionPreCommitOrIdle
- Wikimedia\Rdbms\Database->endAtomic
- Wikimedia\Rdbms\Database->commit
- Wikimedia\Rdbms\Database->runTransactionListenerCallbacks
- Maintenance::{closure}
- DeferredUpdates::tryOpportunisticExecute [loop restarts]
The job that is getting pushed in [1] is RefreshSecondaryDataUpdate
The jobs in the queue are as follows:
self::$preSendUpdates:
- MessageCacheUpdate
- CdnCacheUpdate
self::$postSendUpdates:
- MWCallableUpdate
- MWCallableUpdate
- MWCallableUpdate
- MWCallableUpdate
- RefreshSecondaryDataUpdate
Do note that we are hitting the self::BIG_QUEUE_SIZEcondition in rMW includes/deferred/DeferredUpdates.php:495-500
The issue is, I believe, that enqueueUpdates is not safe for recursive entrance, as it does not remove items from the queue before inserting them to the job queue (if they are queueable), which causes another opportunity to execute deferred updates.