Mautic Community Forums

Firing off Transactional Mails when there is a Queue


I am trying to figure out if there is a way (even via api) that I can send a transactional email out that will bypass the current mautic queue.

My issue is that I have sending setup as a queue, however I also have transactional mailers that need to go out and are fired off from api calls. Currently I notice they are getting stuck in the queue.

Am I missing something ?

There is no way. Each email in the queue is created equal.

But you can run your email processing cron more frequent then others.

Hey @joeyk I am not sure if I should be very excited about your response or maybe I did not understand. Is there a way to fire off a specific cron job per email id ?

Hey @mikew . Sorry, but there is just no way to do that. There is no option which would decide to send some emails over other emails. First come, first served.

yip this is what I thought.

However this could be a cool feature to add eventually to Mautic. If you are using Mautic for both transactional and marketing mailers I can imagine many others would face a similar challenge.

Yes, there could be 2 folders, transactional and marketing…

If you don’t have a problem using segment emails for transactional emails you can use mautic:broadcasts:send --channel=email --id=11 --batch=50 --limit=50 -vvv
Enter the email ID of the email and rock on. You do have to set a publish date for this function to work. set the batch and limit appropriately to cron timing

Otherwise you can process the campaigns containing transactional emails more frequently by using mautic:campaigns:trigger –campaign-id [CAMPAIGN-ID]

You can add [–kickoff-only] [–scheduled-only] if that helps push them out

1 Like

Correct me if I’m wrong, but in case of queue setting enabled this command will not actually send the email, just queue them, right?

1 Like

You are Correct. Perhaps set up a different mailer for transactional emails only. Symphony seems to support it but i never had to use it. Or disable queue, send emails direct, then re-enable as inelegant as that is.
swiftmailer:spool:send [–message-limit MESSAGE-LIMIT] [–time-limit TIME-LIMIT] [–recover-timeout RECOVER-TIMEOUT] [–mailer MAILER] [–transport TRANSPORT] [-h|–help] [-q|–quiet] [-v|vv|vvv|–verbose] [-V|–version] [–ansi] [–no-ansi] [-n|–no-interaction] [-e|–env ENV] [–no-debug] [–]

1 Like

Hold on.
Different Mailier?
You mean you could use multiple smtps?

1 Like

Maybe. Perhaps using the api as mailer and/or transport would work. I have no idea if it would spool differently or if 2 spools could be designated.
Here is the output from the command help

swiftmailer:spool:send [options]

–message-limit=MESSAGE-LIMIT The maximum number of messages to send.
–time-limit=TIME-LIMIT The time limit for sending messages (in seconds).
–recover-timeout=RECOVER-TIMEOUT The timeout for recovering messages that have taken too long to send (in seconds).
–mailer=MAILER The mailer name.
–transport=TRANSPORT The service of the transport to use to send the messages
-h, --help Display this help message
-q, --quiet Do not output any message
-V, --version Display this application version
–ansi Force ANSI output
–no-ansi Disable ANSI output
-n, --no-interaction Do not ask any interactive question
-e, --env=ENV The Environment name. [default: “prod”]
–no-debug Switches off debug mode.
-v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

The swiftmailer:spool:send command sends all emails from the spool.

1 Like

if we are able to use a different smtp would that bypass a queue ?