8000 Compiled container calls `EventDispatcherInterface::addListener()` with non-callable listener · Issue #42283 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

Compiled container calls EventDispatcherInterface::addListener() with non-callable listener #42283

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.

Sign up for GitHub

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

Jump to bottom
Closed
keulinho opened this issue Jul 27, 2021 · 6 comments
Closed

Compiled container calls EventDispatcherInterface::addListener() with non-callable listener #42283

keulinho opened this issue Jul 27, 2021 · 6 comments
Labels
Bug EventDispatcher Status: Reviewed

Comments

@keulinho
Copy link
Contributor

Symfony version(s) affected: 5.3.4, 5.2.12

Description
The "Backport Type Fixes" commit added a callable type declaration to the $listener parameter of EventDispatcherInterface::addListener(). Adding that type declaration to implementations will break when using the dependency-injection container. The reason is that the dependency-injection container will generate code that calls addListener with an array as listener where at index 0 an closure is passed that will resolve to the object that should be called and at index 1 the method name that should be called is passed. According to the official documentation an array is only considered callable if at index 0 of the array the instantiated object is passed, it seems like passing a closure there is not considered to be callable.

How to reproduce

Add a custom EventDispatcher decorater that uses the addListener() method signature from the interface:

    public function addListener(string $eventName, callable $listener, int $priority = 0): void

Or add that native type declaration to the EventDispatcher implementation.

Configure some event subscriber in the service configuration.

After that the dependency-injection container is broken:

Argument 2 passed to EventDispatcher::addListener() must be callable, array given

Possible Solution
Remove the type declaration from the EventDispatcherInterface again.

Or rework the dependency-injection to call EventDispatcherInterface::addListener() in a way that is compatible with that type declaration.

Additional context
The generated code for the dependency injection container looks like this:

$instance->addListener('kernel.request', [0 => function () {
    return ($this->privates['serviceId'] ?? $this->getService());
}, 1 => 'onKernelRequest'], 0);

That seems to not pass the native callable type declaration.
@keulinho keulinho added the Bug label Jul 27, 2021
@xabbuh
Copy link
Member
xabbuh commented Jul 28, 2021

I am not sure if I really got all the steps that are required to reproduce this. Can you please create a small example application that allows to debug this?

@keulinho
Copy link
Contributor Author

Please take a look at following phpsandbox notebook, the interesting change is the App\EventDispatcherDecorator, that decorates the event_dispatcher service and uses the native type decalrations of the EventDispatcherInterface for the addListener() method.

The notebook uses Symfony Web Skeleton, which already uses the dependency-injection component and has some EventSubscribers configured.

@derrabus
Copy link
Member
derrabus commented Jul 28, 2021 •
edited
Loading

Symfony's own implementations don't have the callable parameter type declaration. It has only been added to the interface. If you removed callable from your implementation as well, you should be good.

That being said, should we remove callable type declarations from the interface again? If all of our own implementations ignore it anyway, why does the interface declare it? /cc @nicolas-grekas

@keulinho
Copy link
Contributor Author

Yes removing the type declaration on the implementation resolves the issue. But IMHO the interface should not use type declarations that can not be used in the implementations.

So removing the type declaration on the interface makes sense to me.

@derrabus derrabus mentioned this issue Jul 29, 2021
Closed
@derrabus
Copy link
Member

PR: #42319

@fabpot fabpot closed this as completed Aug 6, 2021
@nicolas-grekas
Copy link
Member

PR has been rejected, see #42319 (comment) for the reason why.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug EventDispatcher Status: Reviewed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@fabpot @nicolas-grekas @derrabus @xabbuh @carsonbot @keulinho
0