LogicException: The database connection is not serializable

Huh, weird. I already had a similar report recently (#3115179: Exception when saving search index field), but in neither case if have any idea how this would happen. From all I can see, the batch should only contain \Drupal\search_api\Task\TaskManager in its definition, and that already uses \Drupal\Core\DependencyInjection\DependencySerializationTrait. So, not sure how this would happen.
I think without further information on what data structure gets indexed, we won’t be able to get to the bottom of this.

I'm seeing this also:

LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary. Alternatively, look at DependencySerializationTrait as a temporary solution. in Drupal\Core\Database\Connection->__sleep() (line 1574 of core/lib/Drupal/Core/Database/Connection.php).

This occurs while attempting to configure a Solr backend. We had previously employed the Search API Database Search module. That module is now disabled, and the original server and indexes deleted. My guess is that there is still some sort of cruft interfering with the intended operation. I'm fairly stumped at the moment but will do my best to troubleshoot.

Found the problem via the debugger. OpenSolr is providing the path field as "solr/CoreName" with no leading slash, but the module expects one (hence the default value). This isn't exactly the error message I'd have expected, but that single change cleared it.

Thanks for investigating, ethanstraffin! Then this sounds like more of a problem with the Solr backend? Please create an issue there and maybe link this one – I have no idea how one would lead to the other, but if it does, then that’s at least one mystery solved.

Awesome, thanks a lot for debugging this so thoroughly!
Seems this is a bug in the Solr backend plugin, then. The DB backend already implements __sleep() to prevent this problem – Solr should just follow suit.
Moving this issue accordingly.

(Having the server entity not serialize the backend plugin would otherwise also be an option, I guess? But I think I prefer having the backend plugins be serializable. Discussion welcome, though.)

These are the corresponding methods in the database backend:

  /**
   * Implements the magic __sleep() method.
   *
   * Prevents the database connection and logger from being serialized.
   */
  public function __sleep() {
    $properties = array_flip(parent::__sleep());
    unset($properties['database']);
    unset($properties['logger']);
    return array_keys($properties);
  }

  /**
   * Implements the magic __wakeup() method.
   *
   * Reloads the database connection and logger.
   */
  public function __wakeup() {
    parent::__wakeup();

    if (isset($this->configuration['database'])) {
      list($key, $target) = explode(':', $this->configuration['database'], 2);
      $this->database = CoreDatabase::getConnection($target, $key);
    }
  }

Obviously the Solr backend doesn't maintain a database connection ;-)
So let's have a look at the methods implemented in the BackendPluginBase:

  /**
   * Implements the magic __sleep() method.
   *
   * Prevents the server entity from being serialized.
   */
  public function __sleep() {
    if ($this->server) {
      $this->serverId = $this->server->id();
    }
    $properties = array_flip(parent::__sleep());
    unset($properties['server']);
    return array_keys($properties);
  }

  /**
   * Implements the magic __wakeup() method.
   *
   * Reloads the server entity.
   */
  public function __wakeup() {
    parent::__wakeup();

    if ($this->serverId) {
      $this->server = Server::load($this->serverId);
      $this->serverId = NULL;
    }
  }

I assume the error is caused by the logger. The logger is created by the BackendPluginBase. But it's serialization is handled by the Database Backend. This is wrong. Instead of doing the same in other backends, BackendPluginBase should take care about it.

abstract class BackendPluginBase extends ConfigurablePluginBase implements BackendInterface {

  use LoggerTrait;

You’re right, thanks a lot for spotting this! Committed your patch.
However, as you can see in #9, the logger isn’t actually the (only) issue – it’s the $moduleHandler property on the Solr backend plugin. So, that will have to be handled, too – as said, either via DependencySerializationTrait (you’d just have to take care to call both the trait’s method and the parent method) or manually (which would have the downside of needing you to keep it up-to-date every time you add a new service as a property).

Or maybe we should just use DependencySerializationTrait in the backend plugin base class, if we generally expect backend plugins to be serializable? Not sure if that would count as a BC break, though – behavior would change a bit for child classes, which might lead to problems. (Though the ES backend, for one, should be fine – they just return array(); in their sleep() method.)

I'll take a look ...

I'll add DependencySerializationTrait to the Solr Backend.

So I assume that this is fixed now.
Please re-open if not.