Async Bundle Laravel Package

Getting Started

Before writing any code, verify what you're actually installing. The published README contains nothing but a deprecation banner pointing to symfony/messenger and symfony/scheduler; the repository is archived and hasn't shipped a release since November 2022. Treat this package as a migration target, not a dependency.

First steps if you've inherited it:

1. Run composer why etrias/async-bundle to confirm what pulled it in. With zero dependents on Packagist, it was almost certainly added by hand years ago.
2. Inspect vendor/etrias/async-bundle/ — since the README documents no public API, the source (and its DependencyInjection/ extension class) is the only specification you have.
3. Check composer.json for the symfony/framework-bundle version constraint; the 2022 release window means it likely targets Symfony 5.4/6.0–6.2 and PHP 8.0/8.1. Run composer update --dry-run to see whether it even resolves against your current stack.
4. Read the bundle's Resources/config/services.xml (or YAML) to enumerate the tagged services and console commands it registers — those commands are your first integration point.

The first real use case is not wiring it into a controller. It's mapping each console command and service it exposes to its Symfony Messenger equivalent (messenger:consume, messenger:failed:show, a MessageHandler, an async Transport). Do that mapping before touching application code, because every hour spent integrating this bundle is an hour not spent on the migration you'll do anyway.

If you're evaluating this for a new project: don't. Go straight to symfony/messenger (in symfony/messenger core since 4.2) and symfony/scheduler (since 6.3). Both are first-party, maintained, and documented.

Implementation Patterns

Since the package is archived with a stub README, there is no "supported" pattern. The only responsible patterns are containment and exit.

Containment (inherited codebase): isolate the bundle's surface behind your own interfaces so the eventual removal is a one-file change.

// app/Async/DispatcherInterface.php
interface DispatcherInterface
{
    public function dispatch(object $job): void;
}

Wrap whatever the bundle exposes (likely a service you resolve from the container by class name — grep the bundle source for class .* implements) in an adapter implementing your interface. Register the adapter in config/services.yaml. Application code depends only on DispatcherInterface. When you swap to Messenger, you write a MessengerDispatcher adapter and delete the old one — no call-site churn.

Migration mapping workflow:

• Bundle command → messenger:consume <transport>
• Bundle "worker"/"daemon" service → a messenger:consume supervisor (systemd, Supervisor, or Symfony's own --time-limit / --memory-limit flags)
• Bundle's retry/failure handling → Messenger's failure_transport plus a messenger:failed:retry routine
• Bundle's cron-like scheduling (if any) → symfony/scheduler with #[AsSchedule] / RecurringMessage
• Bundle's message/job classes → plain readonly message DTOs handled by #[AsMessageHandler] methods

Integration tip — run both side by side during cutover. Keep the bundle installed but stop dispatching to it; route new work through Messenger first, drain the old queue, then remove the bundle. This avoids a big-bang release.

Testing pattern: assert on your DispatcherInterface with a fake, not on the bundle's internals. You don't want your test suite coupled to unmaintained Symfony internals that break on the next minor bump.

Gotchas and Tips

• Archived means no security patches. An abandoned bundle in your composer.lock will eventually block a Symfony major upgrade (constraints are frozen at 2022 versions). This is the strongest reason to remove it — it's a latent upgrade blocker, not just dead weight.
• The deprecation is the documentation. There is no API reference, no upgrade guide, and no changelog beyond a version tag. Assume the source is the spec and budget time to read it rather than searching for docs that don't exist.
• Don't composer require it "to try it out" on a project you care about. With no dependents and no maintainer, any issue you hit stays hit. Prototype directly against Messenger instead.
• Pinning won't save you. Even a locked composer.lock gets re-resolved on composer update, and PHP/Symfony minimum bumps will force it out. Plan the removal as a tracked ticket with a deadline, not a "someday."
• Check for abandoned transitive deps. A 2022 bundle often pins packages that are themselves abandoned. Run composer outdated --direct and composer audit after removal to confirm you didn't inherit a second dead dependency that was only kept alive by this one.
• Watch for container-cache surprises. Old bundles frequently use deprecated Symfony\Component\DependencyInjection patterns (e.g. non-autowired definitions, service locators). Run bin/console debug:container --tag=<tag> to see what it registered before you rip it out, so you know what else might reference those service IDs.
• Extension point that actually matters: config/packages/async.yaml (or whatever the bundle's alias is — check getAlias() in the extension class). Any app config referencing that alias must be deleted alongside the bundle or your container will fail to compile.
• If you have in-flight jobs at cutover: don't just uninstall. Drain the queue, or write a one-off consumer that reads the old transport and re-dispatches into Messenger, then retire it. Silent job loss is the classic migration failure mode here.