Poor man’s Drupal testing with search reindexing

On a recent Drupal 8 project, a coworker set up a regularly scheduled build to do a full search reindex on our test environment. I thought this was strange at first, but it turned out to be an absolute lifesaver on multiple occasions.

Occasion 1: catching invalid entity references

One day, the search reindex build started consistently failing. It was complaining about a line of code that grabs the loaded entity from an entity reference field. The code looked like this:

if (!$node->get('field_image')->isEmpty()) {
  $image_path = $node->get('field_image')->entity->get('field_media_image')->entity->getFileUri();
}

Looks straightforward, right? If the Image field isn’t empty, grab the referenced entity and use that to get the URI of the actual file.

Once the reindex build started failing, we tracked that down to 4 separate media entities which referenced files that no longer existed. In other words, someone deleted the files that were being referenced by media entities. And because Drupal doesn’t enforce data integrity with entity reference fields, that is allowed to happen.

If a user viewed a page that used any of those 4 media entities, then the page would have shown a 500 error.

Without the search reindex build failing, we would never have caught that before it made it to production and users started complaining about erroring pages. Thanks to that build, we were able to manually correct the data before it became a production issue.

Occasion 2: data loss during module uninstall

We recently spent a significant amount of time trying to uninstall the Multiversion module. If you’re curious, here’s a gist showing what it finally took to get that accomplished.

We thought we had it all working solidly, and then the trusty search reindex build started failing. This time, it was complaining that we had blocks that pointed to non-existent media items. Turns out, the uninstall of Multiversion was deleting about 100 media items due to this issue.

Without the search reindex build, that uninstall hook most likely would have made it to production and caused production data loss. Depending on how long it took for anyone to catch it, that could have been a very painful data restoration process with some sort of hacky manual migration of those entities from a DB backup.

Thanks to the reindex, it was no big deal.

Level of effort

If your build process has access to Drush, and you’re using Search API, this couldn’t be easier.

drush sapi-r && drush sapi-i

That’s all there is to it. Run it nightly, and it’ll be a nice sanity check that your entities are able to render without erroring.