What is wrong?

I'm super confused by this bug, but something in Drupal Search API after version 3.4 is breaking everything in our ensemble. Everything means, every time a Solr Index is called, either on a search result, an autocomplete, a config form or even a simple task like Seeing the http://localhost:8001/admin/config/search/search-api/index/default_solr_index to find out who is tracked or not we get a nasty (white page) error like this:

NOTICE: PHP message: Uncaught PHP Exception 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." at /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php line 1546

Which basically means, something (and i'm looking at you MR. SOLR SEARCH API 👀 ) is injecting not an entityTypeManager container, but probably an entityTypeManager->getStorage as a property in a constructor, or, a specific logger, or something that opens a connection to the DB and keeps it in a property initialized, as i already said, in the constructor. Since many many things, like plugins, etc are serialized by the Symfony Kernel, we end with this quite huge error. Normally, if someone (not us) needs that, you either use a special trait that removes the container on sleep() and restores it on wake() (up), but i don't see the why this is now happening.

That said, it can be something we do/did, and since Solr Search API is now, maybe? trying to cache something or being smarter, it gets stuck in the way. I checked all our source code, like everything, and could not find a single place where we commit such Dependency Injection heresy (well one, in a config form, but that one is never called in a normal request stack and its this weeks code)

I spend 18 hours (with a small pause for Subway and lunch) and i can not find the culprit. 🍭

Removed all our own dependencies, changed the index to only use Pages and Articles, removed our Formatters, our Events and of course all fields. And nothing! Rolled back to 3.4 and all is working, no errors, no messages, nothing, pure Archipelago beauty.

After this, i have to say it could be also any other contributed module interaction or the fact that we are trying to run Drupal core 8.8.1 too.

What is needed?

Fresh, well slept eyes. I would suggest, downloading 3.4 and 3.8 (latest), and doing and full release comparison to understand what changed. Only way we can deal with this since we will want eventually be able to move forward with the newer solarium library too. Also, probably a from scratch deployment with 3.8 and only basic packages could give us a hint. Both options are quite time consuming (days, centuries) so i will move forward on beta2 with 3.4, but this task can not wait longer than beta3.

I have spoken. This is the way 😃

@marlo-longley @giancarlobi thoughts?

esmero / archipelago-deployment

Drupal Solr Search API v3.5+ breaks everything and makes me mad/sad #22

What is wrong?

What is needed?