Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[DependencyInjection][Messenger] Unnecessary autoregistration for BatchHandlerInterface #59912

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
oneNevan opened this issue Mar 5, 2025 · 3 comments

Comments

@oneNevan
Copy link
Contributor

oneNevan commented Mar 5, 2025

Symfony version(s) affected

7.0+

Description

I've faced a scenario, when I want my batch handler to be handling messages only from specific transport, and for that I'm adding corresponding AsMessageHandler attribute with fromTransport option, but when I do so, MessengerPass registers two separate HandlerDescriptors inside the HandlersLocator, as it now has two messenger.message_handler tags (one with from_transport opiton, another - without)

As the result, MyBatchHandler starts consuming MyMessage from any transport, which is not I expected.

How to reproduce

  1. Install symfony/messenger component
  2. Create the following handler and message
<?php

namespace App;

use Symfony\Component\Messenger\Attribute\AsMessageHandler;
use Symfony\Component\Messenger\Handler\Acknowledger;
use Symfony\Component\Messenger\Handler\BatchHandlerInterface;

#[AsMessageHandler(fromTransport: 'custom')]
class MyBatchHandler implements BatchHandlerInterface
{
    public function __invoke(MyMessage $message, ?Acknowledger $ack = null): null
    {
        // dummy
        return null;
    }

    public function flush(bool $force): void
    {
        // dummy
    }
}

class MyMessage {
}
  1. Run bin/console debug:container MyBatchHandler and see two messenger.message_handler tags (one expected)
  2. Run bin/console debug:messenger and see there are two handlers for MyMessage class (one expected)

Possible Solution

I'd suggest removing change introduced in PR #44490 and let people add #[AsMessageHandler] attribute manually as recommended for regular handlers - this would be more intuitive for developers IMO

As this is a BC break, it's probably best to introduce this change in symfony/messenger v8.0

As a workaround, it's possible to opt-out from auto-registration for this particular handler and declare handler tag manually:

#config/services.php
<?php

declare(strict_types=1);

use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;

return static function (ContainerConfigurator $container, string $env): void {
    $services = $container->services();
    $services->defaults()
        ->autowire()
        ->autoconfigure();
    
    // other autoconfigured services

    $services
        ->set(\App\MyBatchHandler::class)
        ->autoconfigure(autoconfigured: false)
        ->tag('messenger.message_handler', [
            'from_transport' => 'custom',
        ]);
};

Additional Context

Image

bin/console debug:container MyBatchHandler
Image

bin/console debug:messenger
Image

@oneNevan oneNevan added the Bug label Mar 5, 2025
@oneNevan oneNevan changed the title Unnecessary autoregistration for BatchHandlerInterface [Messenger] Unnecessary autoregistration for BatchHandlerInterface Mar 5, 2025
@oneNevan
Copy link
Contributor Author

oneNevan commented Mar 5, 2025

Additional info (discussed here):

With AsMessageHandler attribute introduction the old MessageHandlerInterface was deprecated and finally removed in symfony 7.0, but when autoregistration for MessageHandlerInterface was removed, the same autoregistration for BatchHandlerInterface was left in place, so I think it is a mistake, and it's better to use the explicit declaration via the attribute, same as regular handlers

@oneNevan oneNevan changed the title [Messenger] Unnecessary autoregistration for BatchHandlerInterface [DependencyInjection][Messenger] Unnecessary autoregistration for BatchHandlerInterface Mar 5, 2025
@GaryPEGEOT
Copy link
Contributor

Underying issue is, shouldn't the auto-configuration be skipped if the tag / config is explicitly configured?

@oneNevan
Copy link
Contributor Author

oneNevan commented Mar 5, 2025

shouldn't the auto-configuration be skipped if the tag / config is explicitly configured?

I don't think so, AFAIK it never worked this way by DI design, you need to manually disable autoconfiguration if you want to

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants