Problem/Motivation

In my case, I'm getting this scenario in monitoring tests #3495046: Fix test fails on Drupal 11 because I need to simulate that hooks are going away to rebuild my sensors accordingly. I can work around it there with a container rebuild.

However, I believe this can happen in real-world scenarios as well, typically when updating a module without properly rebuilding the container. You should of course do that, but we know that people often don't.

Steps to reproduce

Visit the status report. Delete one of the requirements hook, refresh the page.

Proposed resolution

Add an is_callable() check to invokeAll. maybe invoke() too.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3495051

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:

Comments

berdir created an issue. See original summary.

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

nicxvan’s picture

Component: base system » extension system
nicxvan’s picture

Is this a duplicate? I can't find the other issue at the moment.

berdir’s picture

Not strictly a duplicate but at least related to #3549397: [regression] Uninstalling and installing modules during config:import can lead to fatal errors and doing this would avoid that issue.

nicxvan’s picture

Thank you that was the one!

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

nicxvan’s picture

smustgrave’s picture

Status: Active » Closed (duplicate)

Since #9 is in review going to mark this as duplicate and carry over credit.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

nicxvan’s picture

Status: Closed (duplicate) » Active

Actually let's keep this one, it's older, let me move the MR over from: #3622228: Skip stale hook registry entries to prevent WSOD

The reproduction steps are simpler here so I'm not going to move those over.

The related issue mentions:

Drupal 10 tolerated this: ModuleHandler::verifyImplementations() dropped implementations whose function had gone and carried on.

When I investigated this, it does not seem to be entirely accurate, verifyImplementations runs during the caching which while similar to the current getHookImplementationList I think could run much later.

We could explore skipping during getHookImplementationList and leaving the execution time the same.

My concern remains what happens when there is a critical hook for data integrity?
What happens when a race condition ends up with no hook implementations, a WSOD may be preferable.

nicxvan’s picture

Status: Active » Closed (works as designed)

I had a discussion with @ghostofdrupalpast and he articulated what I was struggling with on this issue.

This issue is a symptom not the root cause.

If files change it are deleted a container rebuild is required full stop.

There is an issue for resolving some race conditions that exist: #3616465: Potential race condition in container rebuilds I'll try to take a look this week.

I think this will make it easier too #3618707: Add hook data cache service

I'm going to close this works as designed and work on the other issues to resolve the root cause.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.