What is the intended behaviour when queueing template messages, doing the rendering before enqueuing the message for async sending, OR just before actually sending the message to the mailer transport?

In other words, is rendering intended to be done before dispatching to the messenger's bus?

I think this clarification is important for a fix.

One benefit of rendering the template BEFORE queuing, is: the extensions have access to the request context.

• can render absolute links with scheme and domain
• have access to the logged user

When switching to async, you have to provide the needed context (ie.framework.router.default_uri, or passing context in therender method).

Rendering template is fast. I'm not sure adding such complexity and bugs worth it.

@jderusse +1 on rendering before queuing, this also allows to have a minimalist worker application that only takes care of sending ready-to-send emails.

The proposed fix removes the cloning of the message before sending it to theEventDispatcherInterface. This way the message that is transformed by body renderers, etc... is the same that is actually enqueued.

Not sure if the cloning is needed or if removing this can have any other side-effects.

Any ideas? Thanks.

Hi! Can anyone provide any updates or guidance on how to proceed?

Thanks!

Really looking forward to this fix! The change actually revert's@fabpot's intention to not use the same variable name as changed in commit829566c. The actual bug was introduced later in commitfc4be48 with removing the second event dispatched.

Also looking forward to implement this fix, any idea on when can we expect this to be fixed?

Closing as this fix is not valid.
See#47052 and#47049 for more explanations.