symfony: [Messenger] add a handler that processes messages on kernel.terminate

Can we reopen this discussion? 😄

We’re currently experiencing an issue we would just ❤️ to solve with this.

An old website, running on a legacy server, was updated a while back from SwiftMailer to Symfony Mailer. The major difference between the 2 is that SwiftMailer used memory spool with kernel.terminate by default, while Symfony Mailer integrated the far more generic Messenger component instead. The legacy server is however stuck on a buggy version of Exim which, amongst other things, frequently causes SMTP transactions to hang for seconds.

So, by upgrading to Symfony Mailer, we now have a website that is frequently hanging for multiple seconds on simple postbacks, just because it sends notification emails in the background. The customer of course does not care for all this, and is most certainly not going to allocate budget to allow us to implement Notifier and Messenger properly.

We’re kinda stuck now, while a kernel.terminate transport would be a 2 minute solution to achieve feature parity with the deprecated SwiftMailer.

Given that by now there is already a functional in-memory transport shipped with Messenger out of the box, actually ‘spooling’ it in kernel.terminate would only need a single flag.

The scenario is actually still really relevant these days. For example we pretty frequently use SMTP transports to route emails via Office365 Send Connectors, a great way to get full DKIM/DMARC/SPF compliance and improve spamfilter trust for important emails like invoices on behalf of an organization. Mandrill/MailChimp et al also support and even encourage SMTP routing. Without async message handling, this always means introducing network risks (delays/disconnects) in code that should just be responding with ‘Invoice queued for delivery’ to the browser and THEN doing the possibly slow stuff.

Not sure if this is desirable for two reasons: explicitness and the fact that anything done in kernel.terminate is really hard to debug.

If I have to explicitly configure the handler it’s sufficiently explicit, and the second argument also goes to some extent for most other transports, as Redis PubSub and RabbitMQ all don’t support ‘queue peeking’. Only the Doctrine transport is really well debuggable. Frameworks are about choice, I should be able to do potentially stupid things if there are scenarios that warrant them.

Ok great, will update PR with that new approach, thxs.

I think it would be good to see this as a transport. Because it would be super easy for a user to configure.

For example:

# config/packages/messenger.yaml
framework:
  messenger:
    transports:
      later: symfony://kernel.terminate

    routing:
      'App\My\Message': later

Ok thanks. It would have been a great, simple and standardized way to “just send that job to kernel.terminate”. I guess the most simple way. And all that without having to register an eventlistener, or running the consumer process. Still you can use a logger to debug errors…

The simplest is to not use async messages if you don’t have a suitable transport.