From T293263: [SPIKE] Investigate getting number of past block for IP (including IP ranges) [8H]
Since the current intention is to delay the purge for 90 days, there's no need to revisit the schema of the ipblocks table.
This task should only be done after T297185: [SPIKE] Identify areas affected by delaying purging of blocks by X days [8H] and any tickets it spawns (ie. when we're sure we won't introduce side effects by doing this).
Tagging @TThoabala @AGueyte @phuedx @Tchanders who were involved in the original spike in case they have more insight than me. From what I can tell, maintenance/purgeExpiredBlocks.php runs a single function:
public function execute() {
$this->output( "Purging expired blocks...\n" );
MediaWikiServices::getInstance()->getDatabaseBlockStore()->purgeExpiredBlocks();
$this->output( "Done purging expired blocks.\n" );
}which is defined in includes/block/DatabaseBlockStore.php:
/**
* Delete expired blocks from the ipblocks table
*
* @internal only public for use in DatabaseBlock
*/
public function purgeExpiredBlocks() {
if ( $this->readOnlyMode->isReadOnly() ) {
return;
}
$dbw = $this->loadBalancer->getConnectionRef( DB_PRIMARY );
$blockRestrictionStore = $this->blockRestrictionStore;
DeferredUpdates::addUpdate( new AutoCommitUpdate(
$dbw,
__METHOD__,
static function ( IDatabase $dbw, $fname ) use ( $blockRestrictionStore ) {
$ids = $dbw->selectFieldValues(
'ipblocks',
'ipb_id',
[ 'ipb_expiry < ' . $dbw->addQuotes( $dbw->timestamp() ) ],
$fname
);
if ( $ids ) {
$blockRestrictionStore->deleteByBlockId( $ids );
$dbw->delete( 'ipblocks', [ 'ipb_id' => $ids ], $fname );
}
}
) );
}afaik you'd need to update [ 'ipb_expiry < ' . $dbw->addQuotes( $dbw->timestamp() ) ], to reflect the 90 day delay. As a bonus, you could also confirm that the script runs regularly (daily?) as expected. Presumably it does, as we regularly purge blocks, but I don't know anything about that.
AC
- block purges are delayed by 90 days after expiry
- confirm maintenance script runs regularly as expected