getEntityClass() must be of the type string, null returned

Same problem here with 9.3.5. I'm within a batch too:

// $this->storage is injected, it's Drupal\Node\NodeStorage
$this->storage->loadMultiples($ids);
// this calls
$this->doLoadMultiple($ids); // on EntityStorageBase
// which calls 
$this->getFromStorage($ids); // on SqlContentEntityStorage
// which calls
$this->mapFromStorageRecords($records); // on SqlContentEntityStorage. $records is an array of stdClass containing the raw DB nodes
// which calls
$entity_class = $this->getEntityClass($bundle); // $bundle is one of the site's bundle names
// which calls
$entity_class = parent::getEntityClass(); // on NodeStorage
// which is a one-liner on EntityStorageBase
public function getEntityClass(?string $bundle = NULL): string {
   return $this->baseEntityClass;
}
// and here is the problem: $this->baseEntityClass is NULL, causing the error

The relevant difference is that the same $this->storage->loadMultiple() works normally outside a batch: seems batch loops miss some entity system initialization. These same nodes can be loaded:

• on a normal admin page
• on their own node page
• in a Drush Drupal\node\Entity\Node::loadMultiple($ids); call

This looks like it could also be related with https://www.drupal.org/project/drupal/issues/3244802, which changes EntityStorageBase::__set and marks it deprecated.

I did a bisect on our project and the bug appeared at some point between 9.2.12 (working) and 9.3.0 -alpha1 (failing): that limits the potential causes.

We didn't catch it because none of our tests cover batches.

Finished the bisect. The problem appears with revision 02912a44b1363d838a3e906a7f12709481754b8d : the fix for #3246150: Bundle class changes mean the entity class is now determined by the active entity-type definition, which does change EntityStorageBase where the problem is located.

I can't explain why baseEntityClass would suddenly be empty and sometimes not. What exactly happens *before* that other issue? an empty string is just a wrong and bogus as NULL and should fail as well one step later, when trying to create that class.

It's a pretty basic batch, in which steps load a chunk of nodes, update one of its field items, and store the node back. Returning "" from that function does not cause further errors in my case. We don't have more details from the OP, except that it was also in a batch.

Hey @mindaugasd can you provide more detail, as our cases seem to resemble each other ?

New finding: during the batch, $this->getEntityClass() gets called on a NodeStorage for which the constructor was never called.

After further digging, this happens because the NodeStorage is deserialized in Core\Queue\Batch::claimItem and does not contain that field.

ah, now that does make sense.

the private property that we have is breaking DependencySerializationTrait. Change it to protected and it will work.

That said, I strongly recomend to never inject/store storages in a property, inject the entity type manager and get the storage when you need it. See #3162827: Do not instantiate entity storages in constructors of services that do not always need them

Adding Berdir's link to #3162827: Do not instantiate entity storages in constructors of services that do not always need them.

The problem is that if we put the ETM in a batch info instead of the storage, we now get an assertion failed "The container has been serialized" in DatabaseQueue::createItem() because the batch items now contain a service, and since they are arrays by Batch API specification, they cannot use DependencySerializationTrait.

In my case, I just removed it altogether and made the batch operations callback a normal method instead of a static one, and added the DependencySerializationTrait to allow as an instance method, hence needing to serialize the service carrying it. Another solution would have been to use Drupal::entityTypeManager() but that triggers coder warnings.

Thanks for your help finding the issue. We probably want to handle #3197773: add documentation about not injecting entity storage handlers which would have avoided this, now.

Lets keep this open for now, I do think we should think about not using private there.

Drupal 11.1.1
key module 1.x-dev latest as of today
key module 1.19 also affected
symfony mailer lite: 2.0.2

Operation: add a key-override for the smtp username and smtp password of the symfony mailer transport configuration.

The path of the request: /admin/config/development/configuration/key-overrides/add?ajax-form

Same exact error as illustrated above:

TypeError: Return value of Drupal\Core\Entity\EntityStorageBase::getEntityClass() must be of the type string, null