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

Created on 18 February 2025, about 1 month ago

After updating admin_toolbar to version 3.5.2 on latest D10, flushing caches via UI doesn't work anymore:

The website encountered an unexpected error. Try again later.

InvalidArgumentException: The controller for URI "/en/admin/flush" is not callable. in Drupal\Core\Controller\ControllerResolver->getControllerFromDefinition() (line 53 of core/lib/Drupal/Core/Controller/ControllerResolver.php).
Drupal\admin_toolbar_tools\Controller\ToolbarController::create() (Line: 41)
Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition() (Line: 100)
Drupal\Core\Utility\CallableResolver->getCallableFromDefinition() (Line: 50)
Drupal\Core\Controller\ControllerResolver->getControllerFromDefinition() (Line: 65)
Drupal\Core\Controller\ControllerResolver->getController() (Line: 164)
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: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)

🐛 Bug report
Status

Active

Version

3.5

Component

Code

Created by

🇩🇪Germany adam1

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @adam1
  • 🇨🇦Canada infojunkie Vancouver

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

  • 🇺🇸United States jcontreras

    I am having the same issue

  • 🇺🇸United States pday

    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?

  • 🇬🇧United Kingdom SirClickALot Somerset

    Yep, same here.

    Broken after update to 3.5.2

  • 🇮🇳India Raveen Kumar

    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

  • 🇭🇺Hungary tikaszvince

    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.

  • Pipeline finished with Failed
    about 1 month ago
    Total: 344s
    #428738
  • Pipeline finished with Failed
    about 1 month ago
    Total: 348s
    #428745
  • Pipeline finished with Success
    about 1 month ago
    Total: 341s
    #428757
  • 🇨🇭Switzerland berdir Switzerland

    this was added in Add re-index menu Active 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.

  • 🇦🇹Austria maxilein

    can someone make a new release please.

  • 🇨🇦Canada phjou Vancouver 🇨🇦 🇪🇺

    Patch works well, thanks!

  • 🇺🇸United States bsnodgrass

    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.

  • 🇨🇦Canada nicoleannevella

    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.

  • 🇫🇷France dydave

    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!

  • 🇫🇷France dydave

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

    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!

  • 🇮🇹Italy trickfun

    Patch works fine.
    Thank you

  • 🇺🇸United States mihaic

    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 Add re-index menu Active

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

    Thank you

  • Merge request !114Resolve #3507579 "Revert" → (Merged) created by tonytheferg
  • Pipeline finished with Canceled
    about 1 month ago
    Total: 288s
    #430017
  • @dydave, here is a MR for reverting the feature. Please review.

  • Pipeline finished with Success
    about 1 month ago
    Total: 358s
    #430019
  • 🇩🇰Denmark uv516 Denmark

    I am getting this error on " Flush all caches" and on pressing "continue" in "Run update":
    (the function "runReindexSite" don't exists)

    The website encountered an unexpected error. Try again later.

    ReflectionException: Method Drupal\admin_toolbar_tools\Controller\ToolbarController::runReindexSite() does not exist in ReflectionMethod->__construct() (line 135 of core/lib/Drupal/Core/Entity/EntityResolverManager.php).
    Drupal\Core\Entity\EntityResolverManager->setParametersFromReflection(Array, Object) (Line: 221)
    Drupal\Core\Entity\EntityResolverManager->setRouteOptions(Object) (Line: 48)
    Drupal\Core\EventSubscriber\EntityRouteAlterSubscriber->onRoutingRouteAlterSetType(Object, 'routing.route_alter', Object)
    call_user_func(Array, Object, 'routing.route_alter', Object) (Line: 111)
    Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'routing.route_alter') (Line: 189)
    Drupal\Core\Routing\RouteBuilder->rebuild() (Line: 83)
    Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild() (Line: 485)
    drupal_flush_all_caches() (Line: 206)
    Drupal\admin_toolbar_tools\Controller\ToolbarController->flushAll()
    call_user_func_array(Array, Array) (Line: 123)
    Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
    Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
    Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
    Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
    Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
    Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
    Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
    Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
    Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
    Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 116)
    Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 90)
    Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
    Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
    Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
    Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
    Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
    Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

  • The MR reverts Add re-index menu Active as mentioned in multiple comments.
    See #10, #15, and #19.

    Thanks

  • 🇺🇸United States drewcking

    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!

  • 🇬🇧United Kingdom SirClickALot Somerset

    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 ;-)

  • 🇫🇷France dydave

    dydave changed the visibility of the branch 3507579-controller-for-uri to hidden.

  • 🇫🇷France dydave

    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. It's probably best not clutter up the toolbar with every bell and whistle we can think of. 😅

  • 🇳🇿New Zealand ericgsmith

    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 Add re-index menu Active - they should be updated to include that and also list this issue as a known issue.

  • 🇫🇷France dydave

    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 just taking for granted the generated output.

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

     
    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!

  • 🇳🇿New Zealand ericgsmith

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

  • 🇮🇳India keshav patel

    Thanks a lot for saving debugging time.

    Works fine.

  • 🇦🇹Austria kevin.pfeifer

    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.

  • 🇫🇷France dydave

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

    See #28 above.

  • 🇮🇳India anandaakrishnan g a Coimbatore

    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. 🚀

  • 🇫🇷France dydave

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

    Feel free to report back!
    Thanks!

  • 🇫🇷France dydave

    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!

  • 🇩🇰Denmark ressa Copenhagen

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

  • 🇺🇸United States bwoods

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

  • 🇺🇸United States yesct

    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?

  • 🇫🇷France dydave

    @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 🙂!

  • 🇦🇹Austria maxilein

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

  • 🇩🇰Denmark uv516 Denmark

    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.

  • 🇫🇷France dydave

    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!

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024