Derived discovery can result in rebuilding of out of date data (e.g. Block)

Possible duplicate of #2860346: Reset plugin discovery when a module/theme is installed?

I agree. But I think this will be blocked on that issue, as it adds the necessary $this->discovery = NULL; change.

Another case #2902281: Configuration import fails

The issue there is \Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator::getDeriver has a static cache

this at least unblocks my project, no tests etc

sticking here for composer patches sake

1. +++ b/core/lib/Drupal/Core/Plugin/Discovery/ContainerDerivativeDiscoveryDecorator.php
   @@ -32,4 +33,26 @@ protected function getDeriver($base_plugin_id, $base_definition) {
   +   * Disable the use of caches.
   +   *
   +   * Can be used to ensure that uncached plugin definitions are returned,
   +   * without invalidating all cached information.
   +   *
   +   * This will also remove all local/static caches.
   +   *
   +   * @param bool $use_caches
   +   *   FALSE to not use any caches.
   +   */
   

   Can also be {@inheritdoc}

2. +++ b/core/lib/Drupal/Core/Plugin/Discovery/ContainerDerivativeDiscoveryDecorator.php
   @@ -32,4 +33,26 @@ protected function getDeriver($base_plugin_id, $base_definition) {
   +    unset($this->derivers);
   

   This is a weird method. But AFAICS this unset should be wrapped in a if (!$use_caches) {

+++ b/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php
@@ -192,6 +192,9 @@ public function clearCachedDefinitions() {
+    if ($this->discovery instanceof CachedDiscoveryInterface) {

we should trigger a deprecated error in the else section, so we can remove the instanceof check in d9 and force discoveryinterface to extend the cached version

agree on all points from @tim.plunkett review

reroll for 8.6

I think that @larowlan forgot about to change this issue status from needs work to needs review when sent the re-roll of the patch
Changing issue status to needs new

I was having this issue: https://www.drupal.org/project/search_api_autocomplete/issues/2902281#co... during the installation of my site and I solved it applying the patch in comment #12. It works for me.

+++ b/core/lib/Drupal/Core/Plugin/Discovery/ContainerDerivativeDiscoveryDecorator.php
@@ -32,4 +33,26 @@ protected function getDeriver($base_plugin_id, $base_definition) {
+  public function useCaches($use_caches = FALSE) {
+    unset($this->derivers);
+  }

We're adding a method with no usages - that tends to get us into trouble.

There's also no test coverage.

I suspect that #3001284: Allow plugin derivers to specify cache tags tags for their definitions might also help with this.

https://www.drupal.org/project/search_api_autocomplete/issues/2902281

I'm adding the issue mentioned by @rigoucr. The search_api_autocomplete SearchPluginDeriverBase has a static cache $derivatives that breaks our config import:

 [notice] Synchronized configuration: create views.view.contacts.
 [notice] Synchronized configuration: create search_api_autocomplete.search.contacts.
 [notice] Synchronized configuration: create views.view.sg_search.
 [notice] Synchronized configuration: create search_api_autocomplete.search.sg_search.
 [notice] Finalizing configuration synchronization.
In ConfigImportCommands.php line 259:

Unexpected error during import with operation create for search_api_autocomplete.search.sg_search: Unknown search plugin with ID 'views:sg_search'

On the first run of ViewsDeriver::getDerivativeDefinitions the static cache is created (for search_api_autocomplete.search.contacts) but for the second one (search_api_autocomplete.search.sg_search) it uses the static cache that doesn't know about the second view (views.view.sg_search).
The static cache isn't updated when a another view is added (either by module installation or config sync).

Re-rolled patch against 9.4.x. Please review

Back to needs work for #15

Rerolled against #15

Rerolled against #15

Back to NW, #15 needs to be resolved (tests).

The method added (useCaches) was not implemented in the last patch (#26), which is why it fails

Addressed fix against #28 with interdiff

Addressed fix against #30 with interdiff

In #15 @alexpott said this, but this is a method that is implemented because the interface needs it. That's also why #26 failed.

We're adding a method with no usages - that tends to get us into trouble.

So all we need now is for the tests to be added, they can be similar to the tests that were needed to test the CachedDiscoveryInterface in other places I think. Or is it just that we want to test that the cached discovery is implemented? I don't think we need to actually test the caching behavior again here?

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

Moving to NW for the test cases.

Also IS has several proposed solutions. Can we highlight which was chosen please

Thanks

Rerolled patch for 10.1.x, I needed this for very important project.