Silverstripe-framework: Solr auto-update breaks file migration when index doesn't exist yet

[chillu]

When updating a site with an existing fulltextsearch module index, writing files can trigger the solr index update. Usually, the upgrade sequence is dev/build, file migration task, and only then a Solr_Configure and Solr_Reindex. It doesn't make sense to run those reindex tasks before any file migrations.

We need to avoid fulltextsearch triggering anything on file migraiotn

Pulls requests

• [x] https://github.com/silverstripe/silverstripe-framework/pull/8994
• [x] https://github.com/silverstripe/silverstripe-fulltextsearch/pull/255

[robbieaverill]

If you provide extension points we can bake some logic to disable the hook into fulltextsearch

[maxime-rainville]

@ScopeyNZ to the rescue.

I'm pretty sure that's related to SearchUpdater::$flush_on_shutdown.

Should be able to set that config to false in your task

src/Search/Updaters/SearchUpdater.php:164-167

if (self::$processor && !self::$registered && self::config()->get('flush_on_shutdown')) {
    register_shutdown_function(array(SearchUpdater::class, "flush_dirty_indexes"));
    self::$registered = true;
}

That explains the weird trace where flush_dirty_indexes is at the bottom of the trace

[ScopeyNZ]

Setting SearchUpdater::$enabled to false is probably better. The flush_on_shutdown config would prevent the error that we were discussing, but doesn't stop all the other unnecessary processing

[ichaber]

What I've done for the file migration is to deactivate the SilverStripe\FullTextSearch\Search\Extensions\ProxyDBExtension.

if ($_REQUEST['url'] == '/dev/tasks/MigrateFileTask') {
    $proxyOrigConfig = Config::inst()->get(ProxyDBFactory::class, 'extensions');
    $newProxy = [];
    foreach ($proxyOrigConfig as $value) {
        if ($value != 'SilverStripe\FullTextSearch\Search\Extensions\ProxyDBExtension')
            $newProxy[] = $value;
        }
    }
    Config::modify()->set(ProxyDBFactory::class, 'extensions', $newProxy);
}

[ScopeyNZ]

This _should_ be functionally equivalent to configuring SearchUpdater::$enabled = false. The proxy just triggers SearchUpdater::handle_manipulation which checks that config right at the beginning.

[lhalaa]

We've currently used this in our fork from https://github.com/silverstripe/silverstripe-assets/pull/267

// Disable updater when running file migration
if (ProxyDBFactory::has_extension(ProxyDBExtension::class)) {
    $this->logger->info('Disabling search updater to stop triggering index updates during migration');
    SearchUpdater::config()->set('enabled', false);
}

[ScopeyNZ]

Trying to cater for all modules where this might be a problem would be a nightmare. We really need to have some extension point or something so we can disable the config for migrations from the FullTextSearch module.

[maxime-rainville]

@ScopeyNZ So you mean like an extend call on FileMigrationHelper and/or MigrateFileTask that other module could hook into to be notified that we're about to do a lot of file operations?

Maybe we would need a way for them to add their own helper to be fired afterwards once the main migration is done.

[ScopeyNZ]

that other module could hook into to be notified that we're about to do a lot of file operations

Yeah. I guess that's the most appropriate description of the extension point. I can probably get a PR up at some point but given you have context and it's a one-liner, you might be better placed to do it. I can do the patch to fulltextsearch.

[maxime-rainville]

I'll wipe something together quickly.

[maxime-rainville]

Done https://github.com/silverstripe/silverstripe-framework/pull/8994

[maxime-rainville]

I did a PR against against fulltextsearch https://github.com/silverstripe/silverstripe-fulltextsearch/pull/255

[maxime-rainville]

CC have peer reviewed the fulltextsearch PR. All done.