Description
Symfony version(s) affected: 5.2.4
Description
When configuring custom Chatter instances like so
<service class="App\Core\Notifier\Slack\TransportFactory" id="core.notifier.slack.factory.my_app_name">
<argument>%env(SLACK_CUSTOM_DSN_OTHER_THAN_DEFAULT_FRAMEWORK_CONFIG_ONE_WITH_DIFFERENT_CHANNEL)%</argument>
<argument type="service" id="notifier.transport_factory.slack" />
</service>
<service class="Symfony\Component\Notifier\Bridge\Slack\SlackTransport" id="notifier.transport.slack.my_app_name">
<factory service="core.notifier.slack.factory.my_app_name" method="create" />
</service>
<service class="Symfony\Component\Notifier\Chatter" id="notifier.chatter.slack.my_app_name">
<argument type="service" id="notifier.transport.slack.my_app_name" />
</service>
The problem is this code within the Chatter
public function send(MessageInterface $message): ?SentMessage
{
if (null === $this->bus) {
$this->transport->send($message);
return null;
}
And the fact that its $bus argument gets autowired as my configuration has autowiring enabled in defaults.
I had to add autowire="false" to my service, which is quite un-intuitive given I was using a custom setup of the component for the first time.
How to reproduce
Code above should be enough to reproduce or understand the issue.
Possible Solution
I am very unaware what the purpose of that bus is, besides possibly delaying the messages until after the request has been served?
In either case, it looks like a design flaw to me. Why not decorate the transport with a service that depends on the Bus implementation?, so rather than directly sending through the transport, messages are sent to the bus first, and then through the transport, somehow.
Anyhow, I was only attempting to send a message to a different channel in Slack, so we're probably looking at the wrong barn.
I think we should focus efforts on figuring out why setting a recipieng other than the default channel in slack won't work, then this is a no-issue as far as one is only attempting to send messages to another channel.
If however somebody needs to send messages to several Slack (or any other service?) apps, it gets ugly again, because once the Bus sneaks in, everything is sent through the default Chatter instance.
Additional context
My goal was to be able to send messages to separate channels. The problem is, setting the recipient @ the MessageOptionsInterface instance (in my case, SlackOptions) did not work. I have investigated to the point where calling $message->getRecipientId() in doSend of SlackTransport returns NULL regardless of what I do, when using either of the transports: The default one defined by the framework, or my custom instances.
At present, my services are configured with an explicit autowire="false" to avoid injecting the Bus, and they work because I use a different DSN for each, which has the channel defined in the DSN. Even so, trying to send to another channel (for testing the sake of testing this issue) via MY OWN SERVICE ID, which avoids the Bus thingy, configuring another channel in the message's options still won't work. I did not investigate further why that is.