Hey!

I think @ruudk has recently worked with this code. Maybe they can help review this?

Cheers!

Carsonbot

Could you please add some tests cases that show this fix is needed.

@ruudk I have added assertions for this condition.

@ruudk are there any updates with this pr?

I checked it out but don't really understand what this fixes and how it's needed. But I just wanted you to add tests because that is something the Symfony reviewers will require anyway. So you have to ask somebody from the core team to have a look.

Please describe exactly the case that is broken right now (with examples for instance). Evaluating a fix for an issue that is not fully understood is hard.

@stof I have added a test case to check this problem, you can find it in PriorityTaggedServiceTraitTest.php.

The problem is quite simple: when iterating services with $tagName instead of TaggedIteratorArgument, and the service is described with AsTaggedItem, the priority defined in AsTaggedItem will not work.

@stof any update?

PING @stof

I can confirm this problem but this solution did not work for me.

I have an interface marked with AutoconfigureTag and one of the implementations marked with AsTaggedItem(priority: 10). When injecting using TaggedIterator, the priority is ignored. I had to use AutoconfigureTag on the implementation I want priority 10 for it to work.

Are we talking about the same problem?

I've created a reproducer that demonstrates my problem: https://github.com/kbond/symfony-reproducer/tree/as-tagged-item (commit). When running bin/console debug:container --tag some_tag you can see the priority from AsTaggedItem is ignored. /cc @nicolas-grekas.

I've created a reproducer that demonstrates my problem: https://github.com/kbond/symfony-reproducer/tree/as-tagged-item (commit). When running bin/console debug:container --tag some_tag you can see the priority from AsTaggedItem is ignored. /cc @nicolas-grekas.

@kbond In your reproduce repo, I added a command and used the following code to inject implementations:

#[AsCommand('app:test')]
class TestCommand extends Command {
    public function __construct(#[TaggedIterator('some_tag')] iterable $services) {
        var_dump(iterator_to_array($services));
        parent::__construct();
    }
    public function execute(InputInterface $input, OutputInterface $output): int { return Command::SUCCESS; }
}

Adjusted priority attributed on SomeImplementation does make the order change correctly. That means this works correctly.

As a supplement, here is the Kernel class for your repo to reproduce the problem this PR fixes:

class Kernel extends BaseKernel {
    use MicroKernelTrait;
    protected function build(ContainerBuilder $container) {
        $container->addCompilerPass(new class implements CompilerPassInterface {
            use PriorityTaggedServiceTrait;
            public function process(ContainerBuilder $container) {
                var_dump($this->findAndSortTaggedServices(
                    'some_tag', // BAD
                    $container
                ));
                var_dump($this->findAndSortTaggedServices(
                    new TaggedIteratorArgument('some_tag'), // GOOD
                    $container
                ));
            }
        });
    }
}

After applying my patch, the two var_dump print the good value.

But I can confirm there is a bug in DebugBundle (already noticed when I was composing this PR), debug:container cannot display index/priority defined by AsTaggedItem (actually configured and works in the container) because of the way it gets the values.

Ah, thanks @moesoha! I've confirmed the AsTaggedItem works in my app - it's just not displaying in debug:container as you say.

To clarify, my issue is is a separate problem in debug:container?

@kbond exactly.

@kbond your example is the same: AsTaggedItem applies only when requesting for a TaggedIterator, not when "just" getting the list of tags.
#[AutoconfigureTag('some_tag', ['priority' => 10])] is what you might want to add to set the priority for this tag.

I'm closing here because this works as designed. I understand it might not match your expectations, but changing this should be considered as a new feature I guess - not as a bugfix for sure.

Thanks for submitting.

One last note on this: if we were to implement something like you expected, I'd suggest doing it via a tag, eg
['default_attributes', ['priority' => 10]], and we could of course add a dedicated attribute to make it easier to define this tag.

(or maybe ['default_attributes', ['some_tag' => ['priority' => 10]]] for more specificity?).