-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger][Mailer] Ability to choose the Message class used by Mailer::send #36348
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
Comments
I had talked to Jordi about this. Obviously, because the message is wrapped in |
Might help if messages had an interface they can implement to tell Messenger where they should be routed? Just thinking out loud here. |
I think that would be cool too - but there's no decent way (at the moment) for Mailer to communicate that over to Messenger - all the routing config is just the
Ah, this is referring to the *Mailer * transport - not the Messenger transport. It IS confusing in the docs - this section is right after talking about Messenger transports - it confused me just now too. |
Related to #35750 |
Yup of course this would have to be supported in Messenger too, I'm just thinking it might allow smarter routing patterns if the code/message could route itself. It's also dangerous though for sure, it's nice to remain in control in messenger.yaml of the whole routing. |
This PR was merged into the 4.4 branch. Discussion ---------- Moving mailer transport section See symfony/symfony#36348 (comment) I moved this Mailer "transport" section above Messenger so that, if you're reading the Messenger section, you can't accidentally keep reading and think that the "mailer transports" section is talking about Messenger transports. Also, I changed the transport name from `important` to `alternative` just to add some further differentiation. Commits ------- 8700f2e moving mailer transport section
Thank you for this suggestion. |
Yes. I do still think this would be valuable to be able to send transactional emails ASAP, while background emails could be sent at a slower pace. It also seems like it highlight a design flaw in the Messenger/Mailer combo somehow given how hard it is to achieve, so it's probably worth investigating what could be done. I unfortunately don't have enough knowledge about Messenger internals to say. |
Thank you for this suggestion. |
@carsonbot Yes. |
yes |
Thank you for this suggestion. |
Implemented in #47190 |
Thanks! |
…ally (fabpot) This PR was merged into the 6.2 branch. Discussion ---------- [Mailer] Add a way to change the Bus transport dynamically | Q | A | ------------- | --- | Branch? | 6.2 | Bug fix? | no | New feature? | yes <!-- please update src/**/CHANGELOG.md files --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tickets | Fix #36348 <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead --> | License | MIT | Doc PR | This PR relies on #39306. Once merged, this PR will be rebased. This allows overriding the bus transport "dynamically" via the `X-Bus-Transport` header. Commits ------- ffe3600 [Mailer] Add a way to change the Bus transport dynamically
Description
To allow routing different emails to different messenger transports (not mailer transport), it would be good if there was a way to choose the message class used, instead of having Mailer::send hardcode it to
Symfony\Component\Mailer\Messenger\SendEmailMessage
.P.S: I found the docs a little confusing as I tried setting up Mailer + Messenger together for the first time, and as both use "transport", the Mailer docs say to send to another transport you can use an X-Transport header, so I tried setting that to my messenger transport I wanted to route to, and then got an error that the transport didn't exist. Maybe the docs should be more clear there.
Example
I had to copy the entire Mailer class to do this, as there is no easy way to change the message class used, and as anyway it is final. But anyway I hope it illustrates what I am trying to get to.
Now with this I am able to route urgent emails to a different messenger queue which is processed faster.
The text was updated successfully, but these errors were encountered: