Enqueue\MessengerAdapter\QueueInteropTransport internal OptionsResolver failure since 'transport_name' introduction
Closed this issue · 6 comments
Since this Symfony's FrameworkBundle PR was merged (4.3.3):
symfony/framework-bundle@5205108
The internal option resolver of https://github.com/sroze/messenger-enqueue-transport/blob/master/QueueInteropTransport.php makes the constructor fail because the key transport_name
(introduced in commit linked before) is not handled by the option resolver.
Error details:
In OptionsResolver.php line 796:
[Symfony\Component\OptionsResolver\Exception\UndefinedOptionsException]
The option "transport_name" does not exist. Defined options are: "delayStrategy", "deliveryDelay", "priority", "queue", "receiveTimeout", "timeToLive", "topic".
Exception trace:
() at /var/www/html/vendor/symfony/options-resolver/OptionsResolver.php:796
Symfony\Component\OptionsResolver\OptionsResolver->resolve() at /var/www/html/vendor/sroze/messenger-enqueue-transport/QueueInteropTransport.php:60
Enqueue\MessengerAdapter\QueueInteropTransport->__construct() at /var/www/html/vendor/sroze/messenger-enqueue-transport/QueueInteropTransportFactory.php:60
Enqueue\MessengerAdapter\QueueInteropTransportFactory->createTransport() at /var/www/html/vendor/symfony/messenger/Transport/TransportFactory.php:40
Symfony\Component\Messenger\Transport\TransportFactory->createTransport() at /var/www/html/var/cache/dev/ContainerCW1VQ2l/getMessenger_Transport_PublicationsService.php:23
require() at /var/www/html/var/cache/dev/ContainerCW1VQ2l/srcApp_KernelDevDebugContainer.php:441
ContainerCW1VQ2l\srcApp_KernelDevDebugContainer->load() at /var/www/html/vendor/symfony/dependency-injection/Container.php:433
Symfony\Component\DependencyInjection\Container->getService() at /var/www/html/vendor/symfony/dependency-injection/Argument/ServiceLocator.php:40
Symfony\Component\DependencyInjection\Argument\ServiceLocator->get() at /var/www/html/vendor/symfony/messenger/Command/ConsumeMessagesCommand.php:184
Symfony\Component\Messenger\Command\ConsumeMessagesCommand->execute() at /var/www/html/vendor/symfony/console/Command/Command.php:255
Symfony\Component\Console\Command\Command->run() at /var/www/html/vendor/symfony/console/Application.php:939
Symfony\Component\Console\Application->doRunCommand() at /var/www/html/vendor/symfony/framework-bundle/Console/Application.php:87
Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand() at /var/www/html/vendor/symfony/console/Application.php:273
Symfony\Component\Console\Application->doRun() at /var/www/html/vendor/symfony/framework-bundle/Console/Application.php:73
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /var/www/html/vendor/symfony/console/Application.php:149
Symfony\Component\Console\Application->run() at /var/www/html/bin/console:42
messenger:consume [-l|--limit LIMIT] [-m|--memory-limit MEMORY-LIMIT] [-t|--time-limit TIME-LIMIT] [--sleep SLEEP] [-b|--bus BUS] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command> [<receivers>...]
What is the proper approach ?
- make a PR to
unset($options['transport_name']);
like done here: symfony/messenger@326990f - or should we extend the
configureOptions()
method to add support of thetransport_name
key (null || string) ?
According to your preference, I can PR if needed.
Best regards.
+1 to this.
+1
+1
Sigh...
@sroze you might want to install https://probot.github.io/apps/reaction/ to this repository to prevent the above.
While I understand the need to get this functionality asap, spamming people watching the repo with +1 comments is quite annoying.
As far as the solution is concerned, I believe extending configureOptions()
should be the prefered solution? transport_name
could eventually see some use and there should be little harm in adding it as an option, even if it would currently be ignored.
Released 0.3.2 with the merged fix.