Controller for URI "/en/admin/flush" is not callable

Also happens with multilingual option off, i.e. /admin/flush.

I am having the same issue

I'm having this same issue as well. After some digging around, in my instance, the error message is not being captured but occurs when Drupal tries to resolve Drupal\admin_toolbar_tools\Controller\ToolbarController in Drupal\Core\DependencyInjection\ClassResolver::getInstanceFromDefinition():

You have requested a non-existent service "search.search_page_repository"

I don't have search enabled on my site, but once I enable it, the error messages become a little more clear, since I haven't configured search, I just enabled the module:

The "search_page" entity type does not exist.

Once I cleared the cache via drush, the cache flush from the admin toolbar tools started working again.

Is it possibly an issue with an assumption that search will be enabled and configured fully?

Yep, same here.

Broken after update to 3.5.2

Hello everyone,

I was following up on this issue after upgrading the Admin Toolbar module to version 3.5.2 on a fresh installation of Drupal 10 (latest version). However, I was unable to reproduce the issue on my end.(After clearing caches through admin UI)

I've attached a screenshot of my configuration for reference. It would be great if someone could confirm whether the issue persists with the same configuration.

Looking forward to your feedback!

And Thank You.

Best regards,
Raveen Thakur

You can reproduce this with a fresh install of Drupal (10.4 or 11.x) without installing search module
The admin_toolbar_tools submodule does not list search module as dependency. But the ToolbarController requests a service from that module.

Currently we have 3 options:

• downgrade admin_toolbar to 3.5.1
• OR enable search module
• OR disable admin_toolbar_tools module

I think the best solution would be to check if the search module exists before requesting the service from that module.

this was added in #3486841: Add re-index menu with basically no review. The whole feature seems rather naive, it basically assumes that indexing is done in a single cron run.

Seems OK as to get rid of the error, but I'd consider just reverting that feature.

can someone make a new release please.

Patch works well, thanks!

FWIW I just ran a composer update on a site to Core 11.1.3 which also updated Admin_toolbar from 3.5.1 to 3.5.2, and get a similar, though slightly different result.

/admin/flush?token=MtsO... returns the following error:

InvalidArgumentException: The controller for URI "/admin/flush" is not callable. in Drupal\Core\Controller\ControllerResolver->getControllerFromDefinition() (line 37 of core/lib/Drupal/Core/Controller/ControllerResolver.php).

Drupal\admin_toolbar_tools\Controller\ToolbarController::create() (Line: 36)
Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition() (Line: 100)
Drupal\Core\Utility\CallableResolver->getCallableFromDefinition() (Line: 34)
Drupal\Core\Controller\ControllerResolver->getControllerFromDefinition() (Line: 49)
Drupal\Core\Controller\ControllerResolver->getController() (Line: 166)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

I will try to apply the patch after we are done with security updates.

I'm seeing this same error when updating to 3.5.2

Also get the same error when trying to run cron from the UI.

Super nice of you Sascha (@berdir) to take the time to look into this, it's greatly appreciated.

this was added in #3486841: Add re-index menu with basically no review. The whole feature seems rather naive, it basically assumes that indexing is done in a single cron run.

Completely agree... it seems quite unrealistic to get all of site's content re-indexed in a single click cron run...
I completely missed this feature getting merged in 3.x.

Seems OK as to get rid of the error, but I'd consider just reverting that feature.

I would personally be more inclined to revert the feature as suggested, basically revert:
https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/104/diffs
We would have to create a merge request manually since some of the code of the original MR was recently changed and a revert MR can't be created automatically.

Could somebody please help creating a revert merge request that could be tested and more urgently fix issues in projects?

Any suggestions, comments or feedback would be welcome.
Thanks in advance!

Adrian (@adriancid) would you have any objections if we were to revert the changes from merge request MR!104?

Did you perhaps need this feature on projects or had any particular reason to include it in the module?

We would greatly appreciate to have your opinion and feedback.
Thanks!

Patch works fine.
Thank you

+1 diff fixed it.

Hi this broke all our sites today :-(, I would second with @dydave reverting the functionality introduced on:

https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/104/diffs

https://www.drupal.org/project/admin_toolbar/issues/3486841

Meanwhile we locked the composer on the 3.5.1 version until a clear path is provided by maintainers.

Thank you

NR for the revert branch.

@dydave, here is a MR for reverting the feature. Please review.
Maybe we should mark the offending issue as NW.

.

@uv516, I'm not sure if you are taking about my MR, but the MR reverts #3486841: Add re-index menu as mentioned in multiple comments.
Please see #10, #15, and #19.

MR114 does the trick for me; Drupal 10.4.3 + admin_toolbar 3.5.2 + MR114 patch makes editing the Administration menu work properly AND flushing cache work properly, both with the search module installed and not installed.

Thanks @tonytheferg!

Please forgive me if I have completely misunderstood all this but surely it's really wrong to assume the everyone is using the core Search feature.

Personally, I moved to using Search API years and years and have never looked back.

If I'm not talking nonsense here then surely any kind of mass re-indexing using Core Search should be under the purview of a sub-module?

I for one would never want to see a single menu item that purports to reindex all of my Search API indexes - that would be madness ;-)

Nice one @tonytheferg!
Thanks a lot for picking this up, it's greatly appreciated.

I allowed myself to hide MR!113 for now, since we've decided to go with reverting the changes which recently introduced the issue, as summed up at #24, confirmed by #26 .

I've compared the two MRs MR!104 and MR!114, side by side and they are mirrored from what I could see: what's added in the first one is exactly removed in the new one.
Additionally, we're comforted by the fact the tests are passing (with warnings/out of scope), meaning the PHPCS validation and automated tests are passing 🟢
https://git.drupalcode.org/issue/admin_toolbar-3507579/-/pipelines/430019

Therefore, I went ahead and approved the MR for now, pending to be merged, and moved the issue back to RTBC (settled).

I'd just like to get a bit more feedback from users testing the patch on their sites and any potential additional reviews.
If that's fine with you, we could probably get this merged in within the next 24 hours, followed by another bug fix release.

Lastly, as suggested by #26, this feature could still be added back if anybody fancies working on it, but it would have to be a bit more refined or careful, for example, using a sub-module or other methods that would not require additional dependencies to the Search module. In short, we're taking a step back to take new steps forward.

Any feedback, questions or comments would be greatly appreciated.
Thanks everyone in advance!

Great, thanks!

Yes, I think a sub module is a better approach for that feature, or better yet, let it be handled by users in their own custom module.

I don't use core search either. In a module that is used by so many people, it's probably best not clutter up the toolbar with unnecessary bells and whistles that won't be used by everyone.

Reverting I think is good - thanks @tonytheferg and @dydave.

It would be awesome if this can please get committed and release a 3.5.3 version.

The release notes for 3.5.2 also do not mention issue #3486841: Add re-index menu - they should be updated to include that and also list this issue as a known issue.

Great catch Eric (@ericgsmith)! Thanks a lot!

Not sure why this issue wasn't picked up when generating the release notes with drupalorg-cli.... Perhaps because of the syntax of the commit message?!
I'll pay more attention next time and do a quick check in the commit logs, without trusting blindly the generated output.

I edited the notes manually, trying to follow the generated format and added the sections:

• Feature listing the corresponding issue and
• Known issues with a description inspired from #3486841-7: Add re-index menu (thanks @tonytheferg!).

 
Let us know if you spot anything else, we would be glad to make more changes where needed.

Otherwise: no problem at all for creating a new release (3.5.3) as soon as the changes have been merged in.

Thanks again!

Thanks @dydave - appreciate the quick update, that should hopefully save a few people updating before 3.5.3 is tagged. Cheers

Thanks a lot for saving debugging time.

Works fine.

Just curious when this fix will be released?

We have updated a bunch of our websites due to the fact, that Drupal Core security updates were released yesterday.
Therefore, this bug prevents all our customers to clear the cache via the UI.

@kevin.pfeifer: Most likely within then next 12 hours.

See #28 above.

Issue: Cache Flush Not Working in Admin Toolbar 3.5.2 on Drupal 10
After updating Admin Toolbar to version 3.5.2 on Drupal 10, flushing caches via the UI (/admin/flush) results in a Fatal Error (InvalidArgumentException), preventing cache clearing. The error log indicates that ToolbarController::flushAll() is not callable, suggesting a potential issue with controller registration or dependency injection. The issue persists even after clearing caches via Drush (drush cr) and checking module dependencies. Reverting to Admin Toolbar 3.4.x restores functionality, confirming the issue is specific to 3.5.2. Possible causes include a missing service definition, incorrect method call, or a change in the controller structure. To resolve this, maintainers should verify flushAll() registration, check recent changes in 3.5.2, and confirm proper service injection. A temporary workaround is to downgrade to 3.4.x until an official fix is available. Looking forward to insights or a patch from the maintainers. 🚀

🚀Best-Formatted Comment for the Issue Report
Issue Overview:
After updating Admin Toolbar to version 3.5.2 on Drupal 10, attempting to flush caches via the UI (/en/admin/flush) results in an Fatal Error: InvalidArgumentException.

⚡ Error Details:

❌ InvalidArgumentException: The controller for URI "/en/admin/flush" is not callable.
at Drupal\Core\Controller\ControllerResolver->getControllerFromDefinition() (line 53 of core/lib/Drupal/Core/Controller/ControllerResolver.php).
🛠 Steps to Reproduce:
1️⃣ Update Admin Toolbar module to version 3.5.2.
2️⃣ Go to /admin/flush and attempt to flush caches via the UI.
3️⃣ Result: The page fails to load and throws an unexpected error instead.

✅ Expected Behavior:
🔹 Cache flush should execute successfully without errors.

@anandaakrishnan-ga : Please use the following patch :
https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/114.diff

Feel free to report back!
Thanks!

Thanks again everyone for the great help on this issue!

The changes have been merged at #38, followed by the creation of the new release admin_toolbar 3.5.3 available for upgrade.

Marking this issue as Fixed for now.

Feel free to let us know if you have any questions or encounter any issues while using the module, we would certainly be happy to help 🙂.
Thanks again for your help getting this fixed so quickly!

Thanks for a fast release @dydave, it works well!

Another confirmation that this appears to do the trick. Thanks for fixing!

Question: if sites followed https://architecture.lullabot.com/adr/20230929-drupal-build-steps/

where the example build steps begin with

vendor/bin/drush cache:rebuild --yes
vendor/bin/drush updatedb --yes

would that have prevented sites from being impacted by this issue?

@yesct: Yes, I think so.

As described in the IS, this issue only affects operations carried though the Admin Toolbar Tools "flush" features :

flushing caches via UI doesn't work anymore.

I personally didn't notice the issue at first, since I had been mostly using drush cr.

Hope that answers your question.
Thanks again everyone for the positive feedback on the new release 🙂!

drush was not affected. Only the cache clear calls from the UI.

After updating to version 3.5.3, flush works again for me.
However, we are now back to the problem that the dropdown does not always work on hover, which means that you have to click on a menu item with the result that the page changes away from where you are.
See https://www.drupal.org/project/admin_toolbar/issues/3273601 and continue that debate there.

Thanks @uv516! The issue #3273601: Dropdown not working for toolbar_menu menus was re-opened :
Feel free to post your feedback and tests results there.

Thanks in advance!