Automailer Bundle Laravel Package

Getting Started

This is a Symfony2 bundle, not a Composer package Laravel can autoload into service providers, so "getting started" splits into two tracks: evaluating the concept, and (if you insist) running it in a Symfony app alongside your Laravel code.

The concept (what it actually does): it wraps Swiftmailer's spool in a Doctrine-backed implementation. Instead of writing queued emails to disk (swiftmailer.spool.file), it persists Swift_Message objects to a DB table so multiple app servers share the queue and messages survive restarts.

In a Symfony2 app (the intended path):

1. composer require tss/automailer-bundle
2. Register new TSS\AutomailerBundle\TSSAutomailerBundle() in app/AppKernel.php
3. Configure tss_automailer: with your Doctrine connection/table
4. Run app/console doctrine:schema:update --force
5. Point Swiftmailer at the Doctrine spool via swiftmailer.spool service alias
6. Cron app/console swiftmailer:spool:send --env=prod every minute

Where to look first: the DoctrineSpool class (the queueMessage / sendMessage / flushQueue implementation) — that is the whole package. Everything else is DI wiring.

In Laravel (what you should actually do): skip the package. Its day-to-day behavior is what Mail::to(...)->queue(new Mailable) plus the database queue driver already gives you, natively, with retries, backoff, failed-job storage, and Horizon visibility. Your "first use case" — durable, multi-server, restart-safe email queueing — is QUEUE_CONNECTION=database and a Mailable implementing ShouldQueue. Read the bundle's DoctrineSpool only as a reference for how a DB spool differs from a file spool.

Implementation Patterns

If you are modeling your Laravel mail queue on this bundle's design, the patterns it encodes are:

• Spool-as-alias swap. The bundle's real integration point is re-binding the swiftmailer.spool service to DoctrineSpool. That's the Symfony equivalent of swapping the queue connection. In Laravel the analog is config/mail.php 'queue' => ['connection' => 'database'] plus a dedicated emails queue.
• Persist-then-drain. Messages go into a table, and a cron command drains them. This is exactly Laravel's Mailables + queue:work. Implement it as Mail::to($u)->queue((new OrderShipped($order))->onQueue('emails')).
• Shared queue across nodes. The point of the DB spool. In Laravel, the database queue driver gives you this for free; the redis driver is the better upgrade.
• Separate worker pool. The bundle expects swiftmailer:spool:send on its own cron slot. Mirror that with a dedicated supervisor program: php artisan queue:work --queue=emails --tries=3 --backoff=60.
• Transactional enqueue. The spool inserts a row inside the business transaction so failure to enqueue rolls back. In Laravel use DB::afterCommit() or the after_commit queue option to defer dispatch until commit — this is the pattern worth stealing.
• Integration tip if you're bridging Symfony and Laravel (e.g. shared DB, Laravel worker drains Symfony's spool): don't. Run one framework's mailer. If you must, have Laravel read the Symfony spool table and dispatch Jobs — but you will be reimplementing DoctrineSpool in a Laravel job class in ~40 lines, and that is the correct move.

For new Laravel code, the mapping is direct: Swift_Message → Mailable, DoctrineSpool → Illuminate\Queue\DatabaseQueue, swiftmailer:spool:send → queue:work.

Gotchas and Tips

• Abandoned on two fronts. Last release 2017, Symfony2 only. Swiftmailer itself was EOL'd in Nov 2021 and Symfony migrated to symfony/mailer. You will not get PHP 8 support, typed-property fixes, or Symfony 5+/Laravel 9+ compatibility. Treat it as a case study, not a dependency.
• It will not install cleanly in Laravel. There is no bundle bootstrap for the Laravel container; TSSAutomailerBundle expects AppKernel, Symfony DI tags, and app/console. Composer may resolve it but nothing will wire up. Don't burn an afternoon on Symfony\Bundle\FrameworkBundle shims.
• Spool ≠ queue. Swiftmailer's spool has no visibility timeout, no retry counter, no failed-job table, no backoff. Failures are logged and the message is effectively dropped after the send attempt. Laravel's queue does all of this; that delta is the strongest argument for not porting the pattern.
• Cron overlap and lock contention. swiftmailer:spool:send has no built-in lock in older versions — overlapping cron runs on a slow SMTP server will double-send. If you're mirroring this in Laravel, queue:work handles the atomic reserve for you; a naive SELECT … WHERE sent = 0 drain will not.
• Serialization drift. The bundle serializes Swift_Message (headers, attachments, embedded images) into the DB. Changing Swiftmailer versions can break unserialization of in-flight rows — a classic reason DB-spool implementations need a drain-before-upgrade step. Laravel's database driver JSON-serializes jobs and has the same constraint; queue:clear or drain before deploying serialization-changing code.
• Table bloat / no TTL. Nothing prunes sent rows. In Laravel this is queue:prune-batches-style housekeeping you must schedule yourself. Plan a DELETE FROM jobs WHERE created_at < … job.
• Debugging the intended package. When mail "isn't sending" in a Symfony app using this bundle: check the table has rows (spool working) vs. rows stuck with no sentAt (cron not running or SMTP failing). In Laravel the equivalents are SELECT count(*) FROM jobs; and SELECT * FROM failed_jobs;.
• Extension point worth knowing. The bundle's only real seam is the spool service alias — which is the same seam Laravel exposes via the Mail::extend / custom transport mechanism. If you need DB-backed mail behavior Laravel doesn't have, extend the transport, don't emulate a spool.
• Verdict for a Laravel team: 11 stars, zero dependents, dead since 2017. Do not adopt. The one durable idea to carry forward is enqueue within the business transaction and drain on a dedicated worker pool — and Laravel already ships that as Mailables + ShouldQueue + after_commit + a supervisor-managed emails queue.