Score:1

PHP Fatal error: Uncaught ArgumentCountError on Drush run

jp flag

After I updated my site to Drupal 8.9.16 and Drush to 10.5.0 I get the following error PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function when running any Drush command. This only happens on my remote site not on my local site.

The site is still working ok so I was able to clear cache and update the database from the backend of Drupal. I was hoping this would fix the problem but it didn't. I also searched for a solution but none of the topics I found got me the right solution.

Hopefully one of you have a better understanding of what this error means, and can help me fix it.

The full error message is:

PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to function Drush\Application::configureAndRegisterCommands(), 3 passed in /home/user/domains/domain.com/public_html/vendor/drush/drush/src/Runtime/Runtime.php on line 113 and exactly 4 expected in /home/user/domains/domain.com/vendor/drush/drush/src/Application.php:313
Stack trace:
#0 /home/user/domains/domain.com/public_html/vendor/drush/drush/src/Runtime/Runtime.php(113): Drush\Application->configureAndRegisterCommands(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput), Array)
#1 /home/user/domains/domain.com/public_html/vendor/drush/drush/src/Runtime/Runtime.php(49): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#2 /home/user/domains/domain.com/public_html/vendor/drush/drush/drush.php(72): Drush\Runtime\Runtime->run(Array)
#3 /home/user/domains/domain.com/public_html/vendor/drush/drush/drush(4): require('/home/deb in /home/user/domains/domain.com/vendor/drush/drush/src/Application.php on line 313
Fatal error: Uncaught ArgumentCountError: Too few arguments to function Drush\Application::configureAndRegisterCommands(), 3 passed in /home/user/domains/domain.com/public_html/vendor/drush/drush/src/Runtime/Runtime.php on line 113 and exactly 4 expected in /home/user/domains/domain.com/vendor/drush/drush/src/Application.php:313
Stack trace:
#0 /home/user/domains/domain.com/public_html/vendor/drush/drush/src/Runtime/Runtime.php(113): Drush\Application->configureAndRegisterCommands(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput), Array)
#1 /home/user/domains/domain.com/public_html/vendor/drush/drush/src/Runtime/Runtime.php(49): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#2 /home/user/domains/domain.com/public_html/vendor/drush/drush/drush.php(72): Drush\Runtime\Runtime->run(Array)
#3 /home/user/domains/domain.com/public_html/vendor/drush/drush/drush(4): require('/home/deb in /home/user/domains/domain.com/vendor/drush/drush/src/Application.php on line 313
Score:0
cg flag

I had the same problem before and this helped me.

Drush 10 changed some of its services' definitions and before the composer update Drupal DI container was precached. The next call to drush resulted in a service creation error because a cached container had stale service definition.

The solution is to clean the cache_container table (or another place where the container cache is stored) however as was said this brings some discomfort because before using drush deployed somewhere you have to take care of clearing that cache in an automated way. And it can't be drush itself. It can't be something like drush sqlq "truncate table cache_container" or drush sql-connect and SQL query.

hope to work for you too.

Joost avatar
jp flag
Yes I found this thread. And I truncated the table using phpmyadmin but this didn't solve the problem. Or did I misunderstood what I should do to solve this problem?
Yuseferi avatar
cg flag
@Joost. what verion of drush are you using? and do you run the drush in the correct path? `what `drush status` returns to you?
Joost avatar
jp flag
Hi, I'm running Drush 10.5.0 and yes I'm in the right folder when running drush. Drush status also returns the error
hotwebmatter avatar
nr flag
@Joost did you resolve the issue? Clearing caches and truncating tables also did not work in my case, but I have shared another approach which did solve the problem for me.
Yuseferi avatar
cg flag
@hotwebmatter why downvote while it helps for a couple of find it helpful?
hotwebmatter avatar
nr flag
No idea why someone downvoted this. It wasn't me; in fact, I upvoted it!
Score:0
nr flag

I just had this exact problem. In my case, it was caused by duplicate vendor directories after reorganizing the project to follow the recommended project layout.

I had a new ./vendor/ directory in the project root, but I also still had the old ./docroot/vendor/ directory in the document root. (My project is hosted on Acquia; you may need to check for a ./web/vendor/ directory instead.)

To resolve this issue, try deleting the duplicate directory from ./docroot/vendor/ (or ./web/vendor/), committing the changes to your git repo, and deploying the code change to the upstream environment.

That did it for me!

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.