I confirm this bug. In tests it make MailerAssertionsTrait::assertEmailCount seeing twice more messages than expected.

One of the MessageEvent has the $queued property set to true so they are "different".

Problem is that the MessageLoggerListener should check this attribute before adding it to the list.

This issue is applicable on other listener.

If we take the Symfony\Component\Mailer\EventListener\MessageListener the event will be process everytime, causing the renderer to be call twice (for example the Symfony\Bridge\Twig\Mime\BodyRenderer).

I was trying to ignore some event form the listener base on $event->isQueued() but there is a problem of object reference. The message from the event and the message for the envelope is not the same on the the $event->isQueued() === false, which is not the case on the first event.

This is causing problem if we add a recipient on the message since the AbtractTransport will check the recipient from the envelope which will have a reference on the wrong message.

As mentioned already, the 2 events are different. One if for the message that is queued and the other is from when the message is sent.

#36445 fixes the web profiler to make things clearer and less confusing.

Regarding test assertions, I've just tested and it works:

        $this->assertEmailCount(1);
        $this->assertQueuedEmailCount(1);

Yes but the problem is that they are handle twice by the Symfony\Bridge\Twig\Mime\BodyRenderer the $event->isQueued() is never checked... So probably there is a lot of listener that process both event, that should not be the case. Having two different event would solve the issue, otherwise all listener need to be double checked and an issue open directly in each component.

Yes but the problem is that they are handle twice by the Symfony\Bridge\Twig\Mime\BodyRenderer

A side-effect of this is that a TemplatedEmail is rendered twice. If you're using Encore to load CSS inside those templates, then you need to do a manual autowire EntrypointLookupInterface and call reset on it.

I believe the setup to repeat is this:

A) Install mailer AND Messenger
B) But do not route email messages to a transport (so, have them still be handled sync).
C) Send an email - it will be rendered twice. That's normally maybe wasteful, but not problematic. But with EncoreBundle, the second (I think "actual" email) is sent without styles.

Cheers!

@weaverryan I don't get the issue. The message is cloned, so we are indeed rendering the email twice, but that's from 2 different instances (which means that I will close the issue again as there is no "bug" here).

But, back to Encore. Does that mean that you cannot call encore_entry_link_tags twice? So, if I send 2 different emails during the rendering of a page, that would be a problem as well?

Wait, I've just tried to find out. So, if you call encore_entry_link_tags in the main HTML template for the HTTP Response AND use it in an email that is sent on the same page, I get the issue as well.

It means that you can only call encore_entry_link_tags once per Request, right? If that's the case, it's not related to this issue and a more general problem with Encore (sorry, I haven't look at Encore code to see why there is a state in Encore).

But why would we need to render the email twice ? It doesn't make any sens... I understand that the even is dipatched twice (with the isQueued returning true on the first event) but the rendering will be executed twice once for the queued email (that is not sent) and again when the email is sent (via the messenger). Should be open a issue in the twiw-bridge component to make sure the email is justrendered when "isQueued !== false" ?

The queued message should be rendered for the profiler. I don't see any issue here.

Make sens for the profiler but this behaviour should not be triggered when profiler is not aviable (aka in production) but it will

The profiler was just an example. Tests is another one. In any case, we want to run all listeners on both messages to get the same end result (the fact that the email is sent or not is not relevant here). You might have some listeners that could do things differently depending on the queue status though, but I don't think this should be the case for the built-in ones.