Queue factory services do not conform to an interface

Left a small nitpicky but MR appears to have a failure.

Ah yea see what you mean about not being able to use the typehints. In that case rest looks fine.

I'm triaging RTBC issues. I read the IS, the comments and the MR. I didn't find any unanswered questions or other work to do.

Leaving at RTBC;

Have a look at this issue, figure out which should be closed as a duplicate, and check if any changes from the duplicate issue should be incorporated.

Okay, thanks. I closed it as a duplicate.

Committed/pushed to 11.x and cherry-picked to 10.3.x, thanks!

I asked @longwave about potentially backporting this to 10.2 so contrib could use it earlier for 10/11 compatibility, but as far as we know the only contrib module affected is redis, so should probably see if it's a real issue before backporting API additions to a patch release.

That's enough I think we should backport just the interface to 10.2.x.

That looks like just the right amount to backport.

Can we add typehints (both param and return) to the interface and implementation. I think adding a new interface with typehints is more valuable than the backport to 10.2.x. Given there is no interface I think adding typehints should be allowed.

Committed a5826e6 and pushed to 10.2.x. Thanks!

Hey, I noticed that QueueDatabaseFactory was given the new interface, but QueueFactory does not yet implement the new interface. Should I open a new issue, or can that be fixed here?

Argument #3 ($queueFactory) must be of type Drupal\Core\Queue\QueueFactoryInterface, Drupal\Core\Queue\QueueFactory given

Same question as solideogloria, any reason Drupal\Core\Queue\QueueFactory doesn't implement the new interface?

solideogloria, dieterholvoet:
It's best to think of it as the Drupal\Core\Queue\QueueFactoryManager instead.

Constructor & AutowireLocator

Its constructor uses the #[AutowireLocator('queue_factory')] attribute to inject (only!) services tagged as queue_factory.

// Drupal\Core\Queue\QueueFactory
public function __construct(
  Settings $settings,
  #[AutowireLocator('queue_factory')]
  protected ContainerInterface $container,
)

The variable name $container is potentially a bit confusing, it might imply the variable contains all services of the Drupal container when in fact it only contains QueueFactoryInterface tagged services. I would have suggested $queueFactories.
In 10.x, QueueFactory used the deprecated ContainerAwareTrait to access the $container. In this issue it has been replaced with a AutowireLocator attribute in the constructor and I guess it made sense to keep $container as a variable name.

The AutowireIterator (!= AutowireLocator) attribute has also been used in core at a few places, and the associated variable names were always more descriptive.

I hope usage of the AutowireLocator attribute doesn't always equal using the non-descriptive $container variable name.

Tagging Services

Historically, tagging a service was done manually in your services.yml file. Now, with Symfony’s Service Autoconfiguration, any service that implements QueueFactoryInterface automatically receives the queue_factory tag and gets injected in the QueueFactory(Manager). It makes for a better DX.

This happens in CoreServiceProvider.php#L118-119

$container->registerForAutoconfiguration(QueueFactoryInterface::class)
  ->addTag('queue_factory');

Why Not Implement the Interface in the QueueFactory(Manager)?

If Drupal\Core\Queue\QueueFactory implemented the interface, it would be registered among the tagged services and end up in its own injected constructor's $container variable. Though it likely wouldn’t throw a circular dependency error, it's unwanted behavior.

Hope this barf of information makes sense.

----

Edit: If you're asking this question because you are interested in decorating the service, I would indeed create a new issue.