[Console] Cannot change input arguments on ConsoleCommandEvent

[fschmtt]

Symfony version(s) affected

• 6.3
• 5.4

Description

When subscribing to the console.command and modifying the input arguments, the command receives the original, unmodified arguments.

How to reproduce

Create a subscriber changing the input arguments, e.g.:

class ConsumeMessagesSubscriber implements EventSubscriberInterface
{
    public const LOW_PRIORITY_QUEUE = 'low_priority';

    public static function getSubscribedEvents(): array
    {
        return [
            ConsoleEvents::COMMAND => 'onMessengerConsume',
        ];
    }

    public function onMessengerConsume(ConsoleCommandEvent $event): void
    {
        $command = $event->getCommand();

        if ($command === null) {
            return;
        }

        if ($command->getName() !== 'messenger:consume') {
            return;
        }

        $receivers = $event->getInput()->getArgument('receivers');

        if (!\in_array(self::LOW_PRIORITY_QUEUE, $receivers, true)) {
            $receivers[] = self::LOW_PRIORITY_QUEUE;
            $event->getInput()->setArgument('receivers', $receivers);
        }
    }
}

Run bin/console messenger:consume async. The subscriber should add low_priority as an additional receiver. The command receives the unmodified input argument, though:

❯ php bin/console messenger:consume async

 [OK] Consuming messages from transport "async".

Possible Solution

Possibly the input arguments get bound too early. They are bound in both

• symfony/src/Symfony/Component/Console/Command/Command.php

  Line 285 in 6c3d377

  $input->bind($this->getDefinition());

• symfony/src/Symfony/Component/Console/Application.php

  Line 237 in 6c3d377

  $input->bind($this->getDefinition());

Additional Context

No response

[OskarStark]

Can you confirm this bug is also present in 5.4?

[fschmtt]

Yes, just tested this, can confirm this bug exists in 5.4, too.

[chalasr]

This is a known limitation. PR welcome if one wants to give it a try, but I'm going to close here since we already went back & forth without success on this one and concluded it was a won't fix.

[shyim]

Does it make sense then to mention this in the event class?

[chalasr]

Looks sensible to me yes