Problem/Motivation

Drupal\Core\Plugin\DefaultPluginManager uses a $definitions property in Drupal\Component\Plugin\Discovery\DiscoveryCachedTrait to statically cache plugin definitions. When a plugin manager defines a list of cache tags and one of these cache tags is invalidated, only the persistent cache is invalidated, not the static cache.

Proposed resolution

Add a cache.discovery_chain cache backend like cache.asset_chain containing cache.memory and cache.discovery cache backends. This way, static caches are automatically invalidated. The problem with this is that plugin managers not switching to the cache.discovery_chain backend lose the memory cache.

An alternative is to switch the cache.discovery cache backend to a backend chain, but the problem with this is that any sites overriding the cache.discovery backend would lose the memory cache.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3579767

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

dieterholvoet created an issue. See original summary.

sapnil_biswas made their first commit to this issue’s fork.

sapnil_biswas opened merge request !15112

quietone’s picture

quietone commented
Issue summary: View changes

@sapnil_biswas, Welcome to Drupal! If you haven't seen it there is the Drupal Contributor Guide to help find out how we work together on Drupal.

I have restored standard issue template so we can track progress on this issue.

I have not reviewed the MR. It would help though to have the information about the problem and fix only in the Issue Summary. Here, it is in 2 places and thus any reviewer needs to read both to do a proper review.

sapnil_biswas’s picture

sapnil_biswas commented

Hi @quietone,

Thank you for the warm welcome and for restoring the standard issue template — I appreciate it!

Apologies for not structuring the Issue Summary properly earlier. I understand your point about keeping the problem and fix clearly in one place to make the review easier. I’ll update the Issue Summary accordingly so everything is concise and easier to follow.

I’d also really appreciate it if you could take a look at my MR whenever you get the chance and share your feedback. It would help me improve a lot as I’m still getting familiar with Drupal’s contribution workflow.

Thanks again for your guidance!

sapnil_biswas’s picture

sapnil_biswas commented
Status: Active » Needs work
sapnil_biswas’s picture

sapnil_biswas commented
Status: Needs work » Needs review

Hi @quietone,
I’ve updated the issue summary to keep everything clearly in one place and make it easier to review.
Could you please take a look at the MR when you have time? I’d really appreciate your feedback.
Thanks again for your guidance!

smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work

Is this also an AI solution?

Sharing this https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett...

sapnil_biswas’s picture

sapnil_biswas commented

Hi @smustgrave,

Thanks for pointing that out and for sharing the documentation!

I’m still quite new to Drupal contributions, so I really appreciate the guidance. This isn’t intended as an AI-generated solution—I’ve tried to follow the existing issue and approach it accordingly.

Also noted your point about not adding test coverage outside the module—that makes sense. I’ll revisit the MR and make the necessary adjustments.

Please let me know if there’s anything else I should improve. Thanks again for your help!

smustgrave’s picture

smustgrave commented

Appreciate the response @sapnil_biswas.

sapnil_biswas’s picture

sapnil_biswas commented
Status: Needs work » Needs review

@smustgrave moving this back to Needs review.

I’ve reduced the scope to keep the patch focused on the discovery cache issue and adjusted it based on the feedback above. I’ve done my best to align the approach with my current understanding of the expected Drupal core patterns.

If I’ve still missed something or if this should be simplified further, I’d really appreciate any advice or feedback. Thanks again for the review.

smustgrave’s picture

smustgrave commented

Yea but it was still written by AI..

sapnil_biswas’s picture

sapnil_biswas commented

I did use AI as a reference, but I made sure to understand the scope and adjust things accordingly rather than relying on it completely. I’m still getting familiar with Drupal patterns, so I appreciate the feedback and will keep refining this.

sapnil_biswas’s picture

sapnil_biswas commented

@smustgrave I really appreciate your guidance, it’s helping me understand Drupal better.

smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work

So been told this may have been coming out of the GSOC and if true there should be clear warnings and information about using AI.

I’m tempted to close the MR so that a person and not AI can give it a chance since it doesn’t appear to be correct. It’s adding unneeded comments for something that will have to be managed by the team, breaking tests, and one change seems random/out of scope.

So my polite recommendation

If you’re going to use AI avoid the core queue. Team has way too much to look at already that we can’t entertain AI crud.

If you insist on AI try a contrib project that may be more open/friendly to it.

If the goal is to learn turn off AI, do trial and error, do the research, check the git history, etc.