Call to deprecated method loadRevision() of class Drupal\Core\Entity\EntityStorageInterface

[driskell]

Bug report

  x    Call to deprecated method loadRevision() of class Drupal\Core\Entity\EntityStorageInterface:
         in drupal:10.1.0 and is removed from drupal:11.0.0. Use
         \Drupal\Core\Entity\RevisionableStorageInterface::loadRevision instead.

Using phpstan-drupal 1.1.36

Code snippet that reproduces the problem

/** @var \Drupal\Core\Entity\ContentEntityStorageInterface $storage */
$storage->loadRevision(1);

I think this is fixed previously already in #576 but only for RevisionableStorageInterface. I think the issue lies in the way that ContentEntityStorageInterface inherits its interfaces separately with EntityStorageInterface and TranslatableRevisionalStorageInterface which then inherits RevisionableStorageInterface which then inherits EntityStorageInterface. I think perhaps that additional EntityStorageInterface on the ContentEntityStorageInterface gets in the way

[mglaman]

Are you able to add stubs to your project to test out if additional stubs are needed?

This is enough of a data sample to add a proper test here. I thought I did, maybe I was lazy and didn't

[driskell]

I tried to add stub for ContentEntityStorageInterface but to no avail. I think maybe this might extend into issues with @not-deprecated where there is multiple inheritance paths because ContentEntityStorageInterface extends from both EntityStorageInterface and TranslatableRevisionableStorageInterface with the EntityStorageInterface specified first. No matter what I did in the stub files (adding @not-deprecated for loadRevision in all of them for example) I would still get the deprecation error. Even on ContentEntityStorageInterface. Albeit maybe I wasn't doing it right (adding directly into the phpstan-drupal source in vendor and using --debug to avoid cache.)

[heddn]

could we hack core and see if reversing the order of implementing the interfaces fixes things? I'm still seeing this. Will probably just ignore the warnings since it is a false positive, but it would be nice to fix this more properly.

[driskell]

could we hack core and see if reversing the order of implementing the interfaces fixes things? I'm still seeing this. Will probably just ignore the warnings since it is a false positive, but it would be nice to fix this more properly.

To clarify I think I only messed with stubs and not core files - or if I did only minor tweaks like to drop the additional interface. Definitely worth digging into.

[mglaman]

I just realized we could have a proper test for this by scanning some Drupal core code.

With #595 this showed up in the baseline test. So the PHPUnit test would need to scan one of those files and we can try to fix it.

[nicrodgers]

I'm still getting this error even on 1.2.0.

An example line that is triggering it in our custom code:

$paragraph = Drupal::entityTypeManager()->getStorage('paragraph')->loadRevision($paragraph['target_revision_id']);

[mandclu-acquia]

I'm running into this issue as well, using PHPStan Drupal 1.2.10. I got false positives for both loadRevision and deleteRevision.