Iam having the same issue. Sending message async doesn't work. On serialization I recive " A message must have a text or an HTML part or attachments."

Check if your symfony/twig-bundle is in 4.3 version - helped for me

Having exact same problem, and have symfony/twig-bundle:4.4.

Can any of you create a small example application that allows to reproduce the issue?

Sample app showing error: https://github.com/diabl0/async-mailer

I can confirm this issue.

It happens because we cannot normalize RawMessage from Mime component. It has a constructor with required arguments.

We need to use a serializer with the PropertyNormalizer normalizer, then everything will be fine. Im not sure why PropertyNormalizer is not configured by default though...

Actually, i've already written about this bug to fabpot, about 6 months ago i hope, but I can't find it now, so i can't say what he said about this problem.
In my app I'm using Mailer in another already async handler.

For quick fix, my decision was to create custom Mailer (thx to container), to exclude redundant de/normalization.

#services/mailer.yaml
services:
    _defaults:
        autowire: true
        autoconfigure: true
        public: false

    Mailer\Mailer: ~
    Symfony\Component\Mailer\MailerInterface: '@Mailer\Mailer'

# Mailer/Mailer.php
<?php

namespace Mailer;

use Symfony\Component\EventDispatcher\LegacyEventDispatcherProxy;
use Symfony\Component\Mailer\Envelope;
use Symfony\Component\Mailer\MailerInterface;
use Symfony\Component\Mailer\Transport\TransportInterface;
use Symfony\Component\Mime\RawMessage;
use Symfony\Contracts\EventDispatcher\EventDispatcherInterface;

class Mailer implements MailerInterface
{
    private TransportInterface $transport;

    public function __construct(TransportInterface $transport)
    {
        $this->transport = $transport;
    }

    public function send(RawMessage $message, Envelope $envelope = null): void
    {
        $this->transport->send($message, $envelope);
    }
}

I did an ugly trick with serializer, because SendEmailMessage structure is too complicated for json. The special serializer was added to a project

<?php

namespace Fxbo\Serializer;

use Symfony\Component\Mailer\Messenger\SendEmailMessage;
use Symfony\Component\Serializer\Normalizer\ContextAwareDenormalizerInterface;
use Symfony\Component\Serializer\Normalizer\ContextAwareNormalizerInterface;

class SendEmailMessageJsonSerializer implements ContextAwareNormalizerInterface, ContextAwareDenormalizerInterface
{
    public function supportsNormalization($data, $format = null, array $context = [])
    {
        return $data instanceof SendEmailMessage && $format === 'json';
    }

    public function normalize($object, $format = null, array $context = [])
    {
        return [__CLASS__ => addslashes(serialize($object))];
    }

    public function supportsDenormalization($data, $type, $format = null, array $context = [])
    {
        return $type == SendEmailMessage::class && $format === 'json' && isset($data[__CLASS__]);
    }

    public function denormalize($data, $type, $format = null, array $context = [])
    {
        return unserialize(stripslashes($data[__CLASS__]));
    }
}

And one more, I did not find how to inject context to serializer for specific class, so there is a file for exclude attributes:

<?php

namespace Fxbo\Serializer;

use Symfony\Component\Debug\Exception\FlattenException;
use Symfony\Component\Serializer\Normalizer\AbstractObjectNormalizer;
use Symfony\Component\Serializer\Normalizer\ContextAwareDenormalizerInterface;
use Symfony\Component\Serializer\Normalizer\ContextAwareNormalizerInterface;
use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;
use Symfony\Component\Serializer\SerializerInterface;

class FlattenExceptionSerializer implements ContextAwareNormalizerInterface, ContextAwareDenormalizerInterface
{
    /**
     * @var ObjectNormalizer
     */
    private $normalizer;

    public function __construct(ObjectNormalizer $normalizer)
    {
        $this->normalizer = $normalizer;
    }

    public function supportsNormalization($data, $format = null, array $context = [])
    {
        return $data instanceof FlattenException;
    }

    public function normalize($object, $format = null, array $context = [])
    {
        return $this->normalizer->normalize(
            $object,
            $format,
            array_merge($context, [AbstractObjectNormalizer::IGNORED_ATTRIBUTES => ['previous', 'allPrevious']])
        );
    }

    public function supportsDenormalization($data, $type, $format = null, array $context = [])
    {
        return $type == FlattenException::class;
    }

    public function denormalize($data, $type, $format = null, array $context = [])
    {
        return $this->normalizer->denormalize(
            $data,
            $type,
            $format,
            array_merge($context, [AbstractObjectNormalizer::IGNORED_ATTRIBUTES => ['previous', 'allPrevious']])
        );
    }
}

Firstly I added a specific route and serializer, but there is an error when SendEmailMessage goes to failed queue it decoded as json and this task never be processed successfully.

framework:
    messenger:
        serializer:
            default_serializer: messenger.transport.symfony_serializer
            symfony_serializer:
                format: json
        # after retrying, messages will be sent to the "failed" transport
        failure_transport: failed
        transports:
            mailer:
                dsn: "%env(MESSENGER_TRANSPORT_DSN)%"
                serializer: 'messenger.transport.native_php_serializer'
                options:
                    queue_name: mailer
                    auto_setup: false
            failed:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                options:
                    queue_name: failed
                    auto_setup: false
            #...
        routing:
            'Symfony\Component\Mailer\Messenger\SendEmailMessage':  mailer

@TheRatG creating a seperate transport with the native php serializer worked for me.

Wouldn't adding a getMessage() method to RawMessage fix this? My guess is that the problem is not exactly the constructor argument, but that - due to the missing getMessage() method - the Symfony serializer does not include a message key when serializing. Due to this, when it deserializes, the message key isn't there and deserialization fails. It actually is ok that there is a constructor argument, as long as there is a message key in the JSON that corresponds with the $message constructor argument.

not actually solved by the related PR, as it was fixing only the case of serialize($rawMessage)

Having the same issue with fresh Mailer installation (v5.2.3) and amqp transport. For now I had to set serializer: messenger.transport.native_php_serializer in transport's configuration as a workaround.

Hope it will be fixed, but looking at issue's creation date... 🙄

Thank you for reporting the issue still exists. I would be happy to review a PR that fixes this issue.

Im sure that everybody knows that "open source software" means that everybody can help fixing bugs or support the development.

Could someone debug the problem or create a reproducible script (repository) to show this issue?

@Nyholm I believe @diabl0's repo is a good starting point, I've just reproduced the issue locally with it. Also I've changed composer.json:

• "php": "^7.2.5 || ^8.0",
• changed 5.0.* to ^5.0 in every Symfony package requirement and in extra section

and after composer update issue is still there:

% symfony console messenger:consume async

                                                                                                            
 [OK] Consuming messages from transports "async".                                                           
                                                                                                            

 // The worker will automatically exit once it has received a stop signal via the messenger:stop-workers    
 // command.                                                                                                

 // Quit the worker with CONTROL-C.                                                                         

 // Re-run the command with a -vv option to see logs about consumed messages.                               

[error] Error thrown while handling message Symfony\Component\Mailer\Messenger\SendEmailMessage. Sending for retry #1 using 1000 ms delay. Error: "Cannot send a RawMessage instance without an explicit Envelope."

[critical] Error thrown while running command "messenger:consume async". Message: "Could not decode message: Cannot create an instance of "Symfony\Component\Mime\RawMessage" from serialized data because its constructor requires parameter "message" to be present."


In Serializer.php line 84:
                                                                                                           
  Could not decode message: Cannot create an instance of "Symfony\Component\Mime\RawMessage" from seriali  
  zed data because its constructor requires parameter "message" to be present.                             
                                                                                                           

In AbstractNormalizer.php line 394:
                                                                                                           
  Cannot create an instance of "Symfony\Component\Mime\RawMessage" from serialized data because its const  
  ructor requires parameter "message" to be present.                                                       
                                                                                                           

messenger:consume [-l|--limit LIMIT] [-f|--failure-limit FAILURE-LIMIT] [-m|--memory-limit MEMORY-LIMIT] [-t|--time-limit TIME-LIMIT] [--sleep SLEEP] [-b|--bus BUS] [--] [<receivers>...]

2021-03-03T11:10:36+01:00 [info] User Deprecated: Since symfony/messenger 5.1: Invalid option(s) "queue_name" passed to the AMQP Messenger transport. Passing invalid options is deprecated.
2021-03-03T11:10:36+01:00 [info] User Deprecated: Since symfony/messenger 5.2: Using the "getExceptionMessage()" method of the "Symfony\Component\Messenger\Stamp\RedeliveryStamp" class is deprecated, use the "Symfony\Component\Messenger\Stamp\ErrorDetailsStamp" class instead.
2021-03-03T11:10:36+01:00 [info] User Deprecated: Since symfony/messenger 5.2: Using the "getFlattenException()" method of the "Symfony\Component\Messenger\Stamp\RedeliveryStamp" class is deprecated, use the "Symfony\Component\Messenger\Stamp\ErrorDetailsStamp" class instead.
exit status 1

Unfortunately this repo requires local PHP installation (with amqp extension), but it shows the problem which most important part is in the config/packages/messenger.yaml → serializer: messenger.transport.symfony_serializer in the transports' config and Symfony\Component\Mailer\Messenger\SendEmailMessage: async routing.

Thank you.

Could you help me understand why 87f3284 wasn't a fix for this problem? Also, do you have any suggestions for what actually will fix the issue?

@Nyholm AFAIS 87f3284 is related to native PHP serializer but the problem in this issue relates to JSON serialization. The fact that RawMessage has argument in constructor causes Symfony\Component\Serializer\Normalizer\AbstractNormalizer::instantiateObject() to throw MissingConstructorArgumentsException while consuming message.

For reference, this is payload sent to RabbitMQ with messenger.transport.symfony_serializer serializer when sending email using @diabl0's reproducer:

{"message":{"text":"Sending emails is fun again!","textCharset":"utf-8","html":"<p>See Twig integration for better HTML integration!<\/p>","htmlCharset":"utf-8","attachments":[],"headers":{"from":[{"addresses":[{"address":"hello@example.com","name":""}],"name":"From","lineLength":76,"lang":null,"charset":"utf-8"}],"to":[{"addresses":[{"address":"you@example.com","name":""}],"name":"To","lineLength":76,"lang":null,"charset":"utf-8"}],"subject":[{"value":"Time for Symfony Mailer!","name":"Subject","lineLength":76,"lang":null,"charset":"utf-8"}]},"body":null,"message":null},"envelope":null}

I've tested @weaverryan's suggestion and it somehow fixes deserialization issue, but it ends with:

[error] Error thrown while handling message Symfony\Component\Mailer\Messenger\SendEmailMessage. Sending for retry #1 using 1000 ms delay. Error: "Redelivered message from AMQP detected that will be rejected and trigger the retry logic."

[error] Error thrown while handling message Symfony\Component\Mailer\Messenger\SendEmailMessage. Sending for retry #2 using 2000 ms delay. Error: "Cannot send a RawMessage instance without an explicit Envelope."

[error] Error thrown while handling message Symfony\Component\Mailer\Messenger\SendEmailMessage. Sending for retry #3 using 4000 ms delay. Error: "Cannot send a RawMessage instance without an explicit Envelope."

[critical] Error thrown while handling message Symfony\Component\Mailer\Messenger\SendEmailMessage. Removing from transport after 3 retries. Error: "Cannot send a RawMessage instance without an explicit Envelope."

I've just debug it a little and RawMessage's message property was null after deserialization. It seems the root cause of this problem is that Symfony\Component\Mailer\Messenger\SendEmailMessage has constructor argument RawMessage $message while actually Symfony\Component\Mailer\Mailer::send() dispatches SendEmailMessage with Symfony\Component\Mime\Email instance (when using Mailer like docs say). Email is a child class of RawMessage but totally overrides its constructor (in Message parent) and has many other private fields. With RawMessage typing it's impossible to deserialize actual Email.

When I change SendEmailMessage's types from RawMessage to Email whole message is deserialized properly. But I assume it's not the solution, only PoC. However, I think it's now clear what's the problem 😉

Actually looking at the SendEmailMessage usage it could be proper solution to change $message's type to Email since it's used only in Symfony\Component\Mailer\Messenger\MessageHandler with:

$this->transport->send($message->getMessage(), $message->getEnvelope())

where Symfony\Component\Mailer\Transport\TransportInterface::send() expects RawMessage which will be OK with Email instance. I've changed it locally (also removed serializer: messenger.transport.native_php_serializer from transport's config, so it uses the default one which is JSON) and it seems to be working 🎉

FYI: Symfony\Component\Mailer\Mailer::send()'s signature must be changed too to ensure proper type for message passed to messenger's message.

If it's acceptable solution I would like to make PR with this change, let my debug time be awarded 😉

@Nyholm Personally I am not so sure this is Serializer's issue. It looks to me like architectural mistake in Mailer/Mime component - there is SendEmailMessage message and even its name states it's sending Email, not RawMessage which is used in signature. Not to mention RawMessage→Message inheritance which is weird (totally dropped parent class attributes, not called parent constructor). RawMessage seems to be unnatural abstraction layer to me. Code like this confirms my assumptions:

It's from Symfony\Component\Mailer\Envelope, but there are other places with similar workarounds. RawMessage is mainly used for types in signatures while actual usage requires its child classes. Unfortunately it's widely adopted and probably impossible to change at this point.

IMO Mailer/Notifier (and every other component that works with emails) should work with actual Email messages because it's impossible to call Symfony\Component\Mailer\Mailer::send() with RawMessage (well, at least without exlipic Envelope which is not DX-friendly) - it will end up with LogicException regardless of how it's handled internally by Mailer:

Without bus (using TransportInterface):

Event dispatcher:

Messenger bus:

Changing Mailer::send() and SendEmailMessage signatures and using Email would solve this issue and IMO would be generally better since it wouldn't allow developers to get into that LogicException. For now, according to BC-promise, Mailer::send() could simply check if $message is an instance of Email and if not then it should check if $envelope is passed - if not, it could throw exception at this point, without calling transport/dispatcher/bus. It could also trigger deprecation warning and signature could be changed in the next major version. If Mailer::send() can't create Email instance from RawMessage and Envelope, there probably should be DenormalizerInterface implementation for SendEmailMessage object so proper email message would be deserialized.

But it's Symfony's team decision of course 🙂 Maybe it was done this way for a reason I just don't get.

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Could I get an answer? If I do not hear anything I will assume this issue is resolved or abandoned. Please get back to me <3

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!

The issue still exists. I had to use the NativePhpSerializer to make it work.

serializer: messenger.transport.native_php_serializer

just had the same problem, found this issue, it very much is still a problem in 5.3

I have the same issue on 5.3

@xabbuh since you reopened this issue, what are the next steps for this ? We have been using messenger in production for a couple of weeks and being stuck with php-serialization instead of json-based message body is unfortunate. Regarding @Wirone 's comment #33394 (comment) there seem to be a solution but we need a maintainer's input. I would be willing to make the changes if needed.

@florentdestremau I support your change, we need to use JSON instead of php-serialization

@florentdestremau please make a PR, I will review it and hopefully, we can get it merged. This is important feature

I have no idea what is needed so unless a contributor is willing to point out the direction, this isn't going anywhere for now

@Nyholm is there any chance of getting some guidance on this issue? It's blocking a pretty major PR we need to integrate in our next major release of Mautic to switch from Swiftmailer to Symfony Mailer but folks don't seem to be clear on how to proceed.

IIUC, there is no issue to fix in Symfony Mailer, but it's more about the inability to serialize an email to JSON via the Symfony serializer.

@fabpot I don't know if you're familiar with my comment but IMHO there was architectural issue in Mailer/Mime component. I said "was" because I don't use Messenger/Mailer currently and I don't know state of the codebase. But looking at SendEmailMessage at 6.2 it looks like issue remains.

what about widening SendEmailMessage::$message and SendEmailMessage::__construct($message) type to RawMessage|Email ? would that suffice for serializer to handle it properly?

@fabpot please, could you explain why is it designed this way ( #33394 (comment) ) ? 🙏
as you are the author of these classes/logic.
understanding it will be a good start to wrap around this issue.
notably

• the inheritance RawMessage -> Message -> Email
• most (all?) consumer methods are typed to RawMessage
• Email is a child class of RawMessage but totally overrides its constructor
• RawMessage is mainly used for types in signatures

seems to me that RawMessage is kinda substitute for an interface.

Any update on this one?
It seems kind of counter intuitive, having to configure an extra transport (which includes a separate failure transport, too) with native PHP Serializer, while all other transports are working with JSON.
On the other hand, when using SendEmailMessage, you are probably consuming the Mail with Symfony itself.
Don't get me wrong, just wondering if this issue is a won't fix or needs support :)

As rapid fix, I reused the Normalizer provided by @TheRatG (many thanks to them!) to work around this issue. I added a AutoconfigureTag to enable it faster. Tested on Sf 7.4.

namespace App\Serializer;

use Symfony\Component\DependencyInjection\Attribute\AutoconfigureTag;
use Symfony\Component\Mailer\Messenger\SendEmailMessage;
use Symfony\Component\Serializer\Normalizer\DenormalizerInterface;
use Symfony\Component\Serializer\Normalizer\NormalizerInterface;

#[AutoconfigureTag('serializer.normalizer', ['priority' => 500])]
class SendEmailMessageDenormalizer implements NormalizerInterface, DenormalizerInterface
{
    public function supportsNormalization($data, $format = null, array $context = []): bool
    {
        return $data instanceof SendEmailMessage && $format === 'json';
    }

    public function normalize($data, $format = null, array $context = []): float|int|bool|\ArrayObject|array|string|null
    { return [__CLASS__ => addslashes(serialize($data))];
    }

    public function supportsDenormalization($data, $type, $format = null, array $context = []): bool
    {
        return $type == SendEmailMessage::class && $format === 'json' && isset($data[__CLASS__]);
    }

    public function denormalize($data, $type, $format = null, array $context = []): mixed
    {
        return unserialize(stripslashes($data[__CLASS__]));
    }

    public function getSupportedTypes(?string $format): array
    {
        return [SendEmailMessage::class => true];
    }
}

What would be the best long-term solution here?

Should we consider revisiting the RawMessage class so it can be natively supported by the Symfony serializer? That could imply deprecating it in its current form and introducing a new class that would be fully supported wherever RawMessage is currently used.

Alternatively, could introducing a few interfaces help make things more flexible and extensible?

Or would it make more sense to simply include this Normalizer directly in the Mail component?

I'd love to hear your thoughts on the most sustainable path forward.