Serialization of config fails

I can reproduce the issue. It didn't exist when we introduced connectors. So I assume that something changed in Search API or Core that adds the database connection here. I need to do some debugging.

Usually that's a form or other class so with an injected plugin manager/collection that doesn't use the DependencySerializationTrait

That's why we committed #2817341: ConfigurablePluginBase should use PluginDependencyTrait instead of DependencyTrait to Search API and why I'm surprised that the error is back again.

I don't know exactly what changed in core or somewhere else. But I did some debugging. It turned out that there're two problems and at least the first issue is caused by Search API.
The form serialization finally reaches Drupal\Core\Form\FormCache::setCache().
The serialization of the form_state fails because the storage is a property of Drupal\search_api\Form\ServerForm:

class ServerForm extends EntityForm {

  /**
   * The server storage controller.
   *
   * @var \Drupal\Core\Entity\EntityStorageInterface
   */
  protected $storage;

  /**
   * The backend plugin manager.
   *
   * @var \Drupal\search_api\Backend\BackendPluginManager
   */
  protected $backendPluginManager;

  /**
   * Constructs a ServerForm object.
   *
   * @param \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager
   *   The entity type manager.
   * @param \Drupal\search_api\Backend\BackendPluginManager $backend_plugin_manager
   *   The backend plugin manager.
   */
  public function __construct(EntityTypeManagerInterface $entity_type_manager, BackendPluginManager $backend_plugin_manager) {
    $this->storage = $entity_type_manager->getStorage('search_api_server');
    $this->backendPluginManager = $backend_plugin_manager;
  }
}

The storage isn't a service and therefor not unset before serialization by DependencySerializationTrait.
If you edit a new server, it works and the services within the storage are unset during serialization.
When you edit an existing server, it seems that there's in addition a database connection which remains and leads to the exception.

I had a look at the various examples in core. Some machine_name exists properties are implemented the same way as currently in Search API and should potentially lead to the same issue :-(

But a significant amount of implementations do it differently and don't require the storage directly anymore.

I added a patch to follow this pattern. This fixes the cachability of the form_state!

Unfortunately that patch doesn't resolve the complete issue. Now the serialization of the form array is finally reached. But it fails and i'm still debugging ...

No space left on device. lol

Ups, there's a copy and paste error in the patch in #5.

Please note that the Release blocker tag is about Search API Solr Search 8.x-1.0.

It's weird that this is needed again, but the solution looks solid.

However, let's import The server entity class so that it's just Server::load?

However, let's import The server entity class so that it's just Server::load?

No, you need to provide something that could be executed elsewhere in the form engine.
I think my solution is the correct one, as this is the newer pattern in core as well.

In that case, let's get this in.

IndexForm probably needs that too then, even it's not affected (yet) ?

In IndexForm it's different because the storage isn't a property of the form. Nevertheless I extended the patch to be consistent.

OK, the fails are not related to the patch!

It seems like Search API test now fail in general on 8.4.x.

@borisson_: can you RTBC it again to get it in quickly?

Looks good to me as well.

Not totally happy with removing dependency injection, but not unhappy enough to delay the patch if it fixes a release blocker.
So: committed.
Thanks a lot for your work, everyone – especially Markus!

This issue was referenced by @Berdir at #2831940-30: Create file field widget on top of media entity. I posted a suggested generic solution in #2831940-33: Create file field widget on top of media entity.