Sending multiple emails using the TransportBuilder class causes an Zend_Mail exception

[david-kominek]

Preconditions

1. Magento 2.2.3
2. PHP 7.0.12
3. MySQL 5.7.18

Steps to reproduce

1. Fresh install of Magento
2. Make a custom module with 2 observer classes on an event('sales_order_place_after'). Each of these observers should inject the TransportBuilder class and send an email:

$transport = $this->transportBuilder
    ->setTemplateIdentifier('email_template_identifier')
    ->setTemplateOptions([
        'area' => \Magento\Framework\App\Area::AREA_FRONTEND,
        'store' => 1
    ])
    ->setTemplateVars($data)
    ->setFrom($sender)
    ->addTo($mailto);

// important that this is its own line for when we override the transport builder due to how PHP polymorphism works :(
$transport = $this->transportBuilder->getTransport();

$transport->sendMessage();

3. Checkout and place an order.

Expected result

1. Two emails will be sent...

Actual result

1. The first email is sent, the second email is never sent...
2. The second observer will throw an exception in the $transport->sendMessage() function: throw new Zend_Mail_Exception('From Header set twice');
3. The system.log file will show the following line: "[2018-03-21 19:32:06] main.ERROR: From Header set twice [] []"

The issue seems to be that the transport builder is not adequately cleaning up the $message variable after getting the transport. The solution is to overwrite the TransportBuilder class, and in the function getTransport() to the following:

<?xml version="1.0" ?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
	<preference for="Magento\Framework\Mail\Template\TransportBuilder" type="Vendor\Module\Model\Mail\TransportBuilder" />
</config>

class TransportBuilder extends \Magento\Framework\Mail\Template\TransportBuilder
{
    public function getTransport()
    {
        $mailTransport = parent::getTransport();
        $this->message->clearFrom()
            ->clearReplyTo()
            ->clearReturnPath()
            ->clearSubject()
            ->clearMessageId()
            ->clearRecipients()
            ->setParts([]);

        return $mailTransport;
    }
}

Edit: I don't feel that @dimonovp really reviewed this ticket. Can we have it reopened and reviewed?

[magento-engcom-team]

@david-kominek, please refer to the Community Forums or the Magento Stack Exchange site for advice or general discussion about this issue. The GitHub issue tracker is intended for Magento Core technical issues only.

[david-kominek]

OK, so I'm just a little confused. The core team intended the TransportBuilder to be a single use class? The way that it currently is implemented, you can only use the TransportBuilder one time per request, no matter which class you inject it into. I thought the point of a "Builder" class was to be able to build multiple of something.

[sebastian-enz]

@magento-engcom-team Are you sure it is appropriate to close this ticket? This seems to be a real issue. TransportBuilder should not be usable once per request only. For example, what about an extension creating 5 shipments for different orders and emailing them to customers, in "one request/execution" -- right now, using Magento\Sales\Model\Order\Email\Sender\ShipmentSender only the first of the five shipment emails would be sent, as after the first email, the above exception described by @david-kominek is stopping further emails from being sent.

[heldchen]

we have this problem too, first noticed after updating to 2.2.4.

the TransportBuilder uses ObjectManager in reset() to create a "new" \Magento\Framework\Mail\Message instance:

    /**
     * Reset object state
     *
     * @return $this
     */
    protected function reset()
    {
        $this->message = $this->objectManager->create(\Magento\Framework\Mail\Message::class);
        $this->templateIdentifier = null;
        $this->templateVars = null;
        $this->templateOptions = null;
        return $this;
    }

once a mail was previously created, the object returned from the ObjectManager won't be a new, uniinitalized object and thus needs at least be reset properly. or get rid of the object manager stuff as everyone seems to preach nowadays.

[andypieters]

Having the same issue in 2.2.4.
Our payment plugin sends the order confirmation and invoice when the payment is completed.
The order confirmation is sent, the invoice is not.
This worked in the past and it clearly is a bug in magento core.
Iam using \Magento\Sales\Model\Order\Email\Sender\OrderSender and \Magento\Sales\Model\Order\Email\Sender\InvoiceSender to sent those emails.
After debugging, i found out that if i don't send the order confirmation, the invoice email works.
Also got the exception: "From Header set twice"

[heldchen]

here's a core patch: bugfix--allow-more-than-one-email-being-sent.zip

please refrain from commenting the ugliness of the patch - mostly due to the stupidity of this bug. I'm sure someone can come up with a nicer solution eventually by getting rid of this dependency injection/object manager mess introduced in 2.2.4.

[andypieters]

@heldchen Thanks.
But the thing is, i myself am not using magento, i just developed a payment plugin for our clients.
I have the feeling that @dimonovp just closed this issue without even looking at it.
@magento-engcom-team Please have a look at this and re-open this issue. We know about the forums and stack exchange, but this clearly is a bug.

[henk-hypershop]

Is a bug indeed. Please re-open this issue.

[gewaechshaus]

Same here...

[vlauria]

With Magento 2.2.4 the issue is in Magento\Framework\Mail\Template\TransportBuilderByStore, after setFrom not reset header from.

Add this function:

protected function reset()
{
        $this->message = $this->objectManager->create(\Magento\Framework\Mail\Message::class);
        return $this;
 }

and replace function setFromByStore with

public function setFromByStore($from, $store)
{
        $result = $this->senderResolver->resolve($from, $store);
        $this->message->setFrom($result['email'], $result['name']);
        $this->reset();
        return $this;
}

[heldchen]

@vlauria this will still instantiate a new message each time setFromByStore is called, and as such break multiple sending. check the zip I've added a few comments above for a working patch.

[david-kominek]

@magento-engcom-team Could we have this re-reviewed or clarification added? It seems to be an actual issue with a fairly simple solution.

[vlauria]

@heldchen Magento into Magento\Framework\Mail\Template\TransportBuilder after send message instantiate a new message, like my fix.
The problem is that magento use two transport for send mail, in TransportBuilder reset message istance.
In TransportBuilderByStore no.

[ghost]

@david-kominek, thank you for your report.
We were not able to reproduce this issue by following the steps you provided. If you'd like to update it, please reopen the issue.

[heldchen]

this is turning into a farce. the issue is reproducible with the steps in the initial ticket, but you probably ignored with 2 observer classes

[ghost]

@heldchen, you can always create new issue with more obvious steps to reproduce.

[hostep]

Just commenting in here since I've seen other related tickets around this.
Most people in here mention Magento 2.2.4, and in 2.2.4 the Amazon Payment module got included by default, which incorrectly made the Magento\Framework\Mail\MessageInterface non-shared. There is a pending fix over here: amzn/amazon-payments-magento-2-plugin@b9e8dca

And there is also a pending PR for Magento2 which also seems to be around something very similar: #16461

Not sure if this causes the problem discussed in this thread? It seems related.
Opening post mentions Magento 2.2.3, so it might be something completely else, in that case, ignore me :)

[david-kominek]

The original issue is unrelated to the email issues introduced in 2.2.4. I've already got my solution for this issue which I mentioned in the original post. Since Magento team seems unable or unwilling to reproduce, hopefully this post will help those who come across the bug. It seems like it's not going to be resolved.

[gwharton]

@david-kominek Hopefully PR #16461 will be approved and merged soon. This will fix this issue, along with a host of other issues.

It was the fix that was introduced to fix the original email problems, that introduced this new bug. PR #16461 is an alternative fix for the original email issue, but at the same time, does not introduce the new bug that causes the multiple email issues to occur.

Hope this helps clarify.

[gwharton]

Fixed in 2.2-develop
9a7c9e5#diff-dfb3ee5a7f863458afea75f5524cd2e5

[stephan-cream]

The 'fixes' provided in all of the respective tickets/commits linked within the current issue don't actually solve the issue or address the actual issue.

I will briefly explain the issue that occurs as concise as possible.
When framework\Mail\Template\TransportBuilder is instantiated it will fetch a singleton instance of \Magento\Framework\Mail\Message, having MessageInterface $message, in the construct.
This singleton can also be used in other classes during the mail process through the use of dependency injection, the same way as it is done as shown in the __construct of the above class.

The main issue with a singleton is that any data that is set (for example the header in this case) is kept as long as a process is running.
Seeing as a cronjob is a single process the singleton's data, once set, stays filled with whatever is set on the first time within a loop throughout the entire loop.

Example:

Loop 1:
Header = NULL
Header is set to 'A'
Header = A

Loop 2:
Header = A
Error is thrown as the header is filled.

Although the suggested fix from some of the commits in this issue $this->message = $this->messageFactory->create(); might seem to be a fix, in reality you are only replacing the singleton object in the $message variable with a new instance of \Magento\Framework\Mail\Message.
Everywhere else where the singleton is used it will still use the singleton with the old data and not your newly created instance which is only available within the given class as you are not changing the singleton's instance, just the variable's object within the current class.

A singleton is not supposed to be reinstantiated in the first place, the whole purpose of a singleton is to avoid new instances.
As such a better fix would be to reset all the data within the message singleton.
Now i am unsure whether there is an easier way, but the example below would be a way on how to fix this problem. Do note i have tested this thoroughly on multiple custom cronjobs which send order mails, invoice mails and shipment mails as well as custom mails in bulk.

vendor/magento/framework/Mail/Template/TransportBuilder.php
/**
* Reset object state
*
* @return $this
*/
protected function reset()
{
$this->message->clearDate();
$this->message->clearFrom();
$this->message->clearMessageId();
$this->message->clearRecipients();
$this->message->clearReplyTo();
$this->message->clearReturnPath();
$this->message->clearSubject();
$this->message->setParts([]);
$this->templateIdentifier = null;
$this->templateVars = null;
$this->templateOptions = null;
return $this;
}

[magento-engcom-team]

Hi @david-kominek. Thank you for your report.
The issue has been fixed in #18471 by @gwharton in 2.3-develop branch
Related commit(s):

• ad50297e7bf4ea39db62f0969579a1ca8eb5f1a3
• e16ff74e4f5f24a4a2530b6aced6ef50032515e0
• 621d2cfeaf8e0a15e592cdc001c856385b3cbd83
• b6f9e48289119117df230b6578ac9ff3d69e4996
• 0dc85785e522e2be8c72dfeaee7e9f5054195034
• 122019c953037df74ef97245a42b274eae2e6639
• 193c6c2f6facf7276c1c8858d29ea3b847062ef5
• bd0aa57cc837918335015d051f08cf380dc186d0
• 523b0464966f81f1f01aa13073092bfddf363219
• 424929fe9aee1005601cc2c9c7ad0090741be723
• c32ca7a0d58cbc57276349b26eb5ecd38451fd2d
• e39ce7a3f2a7e6ee134cff9a097b7321756c32cf
• 99621b32f8c7d3d12f83db7e67f5f1c1ef3e7f31
• f171c9d6ab035439ffb6374ec14dd8d51123dcd2

The fix will be available with the upcoming 2.3.1 release.

[tuyennn]

@gwharton @magento-engcom-team I'm confusing while it's still an issue after applied the patch on backport for my 2.2.7.
I'm using a observer to send another mail after payment successfully. Even I was trying to set transportBuilder with new implementation

setFromByScope

[gwharton]

Someone from Magento will need to pick this up and look at what needs to be done moving forward.

With respect to updating 2.2 going forward, Magento have stopped accepting fixes for the 2.2 release line now so would need to be pursued in the 2.3-develop line.

[m2-assistant]

Hi @engcom-Bravo. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

• 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).

  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• 4. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

• 5. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• 6. Add label Issue: Confirmed once verification is complete.

• 7. Make sure that automatic system confirms that report has been added to the backlog.

[engcom-Bravo]

This issue is fixed on 2.3.x branches(i tried to reproduce on 2.3-develop).
Thank for contributing!