You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When authoring custom commands, any errors thrown when instantiating the command handler are suppressed and very difficult to identify. The commands just disapear from drush list with no feedback.
I encountered this when I created a command handler in my custom module that uses dependency injection to add services, but had a typo in the service name being injected.
When my command handler's create($container) was called in ServiceManager an exception was generated with a message like "Could not instantiate Drupal\my_module\Drush\Commands\MyCommands: You have requested a non-existent service "entity_type.managerTYPO". Did you mean one of these: ... but this message doesn't get displayed in any output, making it difficult to identify the source of the issue.
To Reproduce
Here's an example of a command handler with this type of typo in the create() function:
<?php
namespace Drupal\my_module\Drush\Commands;
use Drupal\Core\Entity\EntityTypeManagerInterface;
use Drush\Attributes as CLI;
use Drush\Commands\DrushCommands;
use Psr\Log\LoggerInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;
/**
* A Drush commandfile.
*/
class MyCommands extends DrushCommands {
/**
* The Entity Type Manager service.
*
* @var \Drupal\Core\Entity\EntityTypeManagerInterface
*/
protected $entityTypeManager;
/**
* Constructor.
*
* @param \Drupal\Core\Entity\EntityTypeManagerInterface $entityTypeManager
* The EntityTypeManger.
*/
public function __construct(EntityTypeManger $entityTypeManager) {
parent::__construct();
$this->entityTypeManager = $entityTypeManager;
}
}
/**
* {@inheritdoc}
*/
public static function create(ContainerInterface $container) {
return new static(
$container->get('entity_type.managerTYPO'),
);
}
/**
* Do something
*/
#[CLI\Command(name: 'my_module:do_something')]
public function doSomething() {
$userStorage = $this->entityTypeManager->getStorage('user');
// Do something more.
}
}
Running drush list doesn't include my_module:do_something' in the output because the handler instantiation failed, but no warning is displayed or visible.
Expected behavior
I would expect to see a drush warning message indicating that one of the command handlers in an enabled module couldn't be accessed, something like:
Error loading Drush command handler:
Could not instantiate Drupal\my_module\Drush\Commands\MyCommands: You have requested a non-existent service "entity_type.managerTYPO". Did you mean one of these: ...
Actual behavior
Running drush list doesn't include my_module:do_something' in the output because the handler instantiation failed, but no warning is displayed or visible.
Workaround
n/a
System Configuration
Q
A
Drush version?
12.4.3.0
Drupal version?
10.1
PHP version
8.1.27
OS?
Linux
The text was updated successfully, but these errors were encountered:
Describe the bug
When authoring custom commands, any errors thrown when instantiating the command handler are suppressed and very difficult to identify. The commands just disapear from
drush list
with no feedback.I encountered this when I created a command handler in my custom module that uses dependency injection to add services, but had a typo in the service name being injected.
When my command handler's
create($container)
was called in ServiceManager an exception was generated with a message like"Could not instantiate Drupal\my_module\Drush\Commands\MyCommands: You have requested a non-existent service "entity_type.managerTYPO". Did you mean one of these: ...
but this message doesn't get displayed in any output, making it difficult to identify the source of the issue.To Reproduce
Here's an example of a command handler with this type of typo in the
create()
function:Running
drush list
doesn't includemy_module:do_something'
in the output because the handler instantiation failed, but no warning is displayed or visible.Expected behavior
I would expect to see a drush warning message indicating that one of the command handlers in an enabled module couldn't be accessed, something like:
Actual behavior
Running
drush list
doesn't includemy_module:do_something'
in the output because the handler instantiation failed, but no warning is displayed or visible.Workaround
n/a
System Configuration
The text was updated successfully, but these errors were encountered: