Skip to content

[Mailer] Sender address from configuration not used when using aysnc transport #59812

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gremo opened this issue Feb 19, 2025 · 3 comments
Closed

Comments

@gremo
Copy link

gremo commented Feb 19, 2025

Symfony version(s) affected

7.2

Description

Cannot send email messages using the async transport and the sender address configuration. Exception thrown:

"An email must have a "From" or a "Sender" header."

How to reproduce

Set the sender address in the configuration:

framework:
    mailer:
        dsn: '%env(MAILER_DSN)%'
        envelope:
            sender: no-reply@example.com
        headers:
            From: 'Example <no-reply@example.com>'

Send an email without using any transport (sync sending): OK

Send an email using the async transport: KO

Error thrown while handling message Symfony\Component\Mailer\Messenger\SendEmailMessage. Sending for retry #1 using 1060 ms delay. Error: "An email must have a "From" or a "Sender" header." {"class":"Symfony\Component\Mailer\Messenger\SendEmailMessage","message_id":77,"retryCount":1,"delay":1060,"error":"An email must have a "From" or a "Sender" header.","exception":"[object] (Symfony\Component\Mime\Exception\LogicException(code: 0): An email must have a "From" or a "Sender" header. at /app/vendor/symfony/mime/Message.php:132)"} []

Async transport configuration:

framework:
    messenger:
        # Uncomment this (and the failed transport below) to send failed messages to this transport for later handling.
        failure_transport: failed

        transports:
            # https://symfony.com/doc/current/messenger.html#transport-configuration
            async: '%env(MESSENGER_TRANSPORT_DSN)%'
            failed: 'doctrine://default?queue_name=failed'
            # sync: 'sync://'

        routing:
            # Route your messages to the transports
            # 'App\Message\YourMessage': async
            Symfony\Component\Mailer\Messenger\SendEmailMessage: async

Possible Solution

No response

Additional Context

The EnvelopeListener which I suppose is responsible of setting the sender is actually called even using the async transport.

@Staormin
Copy link
Contributor

Staormin commented Feb 19, 2025

Hi, just tried it without any issue with your setup, did you restart the messenger consumer after adding the global from in your config?

@gremo
Copy link
Author

gremo commented Feb 19, 2025

Yes @Staormin a lot of times even rebuilding the Docker image which contains the php worker service (with Supervisor). I'll try bypassing supervisor and using the plain command in the same container, let me check.

@gremo
Copy link
Author

gremo commented Feb 20, 2025

It was simply a cache issue.

Even after restarting the container where Supervisor is installed, the message worker was still reading the "old" cache (for example, the templates were not updated either). Regenerating the cache and restarting the container solved the problem.

I apologize for the inconvenience.

By pure chance, I got an indication of what the problem might be.

While debugging and modifying the Messenger configuration, I forgot the following:

buses:
    messenger.bus.default: []

After adding it, sending emails in synchronous mode works without any issue as before.

However, I get the following error when sending emails asynchronously via messenger:consume async, which runs inside a Docker container through Supervisor:

[2025-02-20T13:23:19.185800+01:00] messenger.WARNING: Error thrown while handling message Symfony\Component\Mailer\Messenger\SendEmailMessage. Sending for retry #1 using 1004 ms delay. Error: "Bus named "messenger.bus.default" does not exist."

Essentially, the process does not seem to recognize that the configuration has been updated, even after restarting the PHP container or restarting Supervisor. I can't fix the configuration in any way, basically.

I'm not sure if this is an issue with my container.

Do you have any idea what might be happening and how I can further debug this problem?

@gremo gremo closed this as completed Feb 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants