Worker Bundle Laravel Package

Getting Started

1. Install the component and bundle. The bundle depends on exsyst/worker, so pull both:

   composer require exsyst/worker exsyst/worker-bundle
   

   There are no tagged releases documented in the README, so expect to land on dev-master and pin a commit hash in composer.json if you need reproducibility.

2. Register the bundle. This is a Symfony2-era bundle, so registration goes in app/AppKernel.php:

   $bundles = [
       // ...
       new EXSyst\WorkerBundle\EXSystWorkerBundle(),
   ];
   

3. Where to look first. The README is badges only — the source is the documentation. Read these in order:

   • DependencyInjection/ — the extension class and Configuration.php tell you the config alias (by convention exsyst_worker) and the available options.
   • DependencyInjection/Compiler/ — this is where worker services get collected into the runtime, usually via a tag. The tag name and required interface are defined here.
   • The exsyst/worker repo itself — the WorkerInterface, JobInterface (or equivalent), and the worker/manager classes you'll implement against.

4. First use case. Define one concrete worker as a Symfony service that implements the component's worker interface, tag it so the compiler pass picks it up, then run it through whatever console command the bundle exposes (check Command/) or by injecting the worker service into a controller/service. Start with a trivial "log a line every N seconds" worker to prove the wiring before adding real logic.

Implementation Patterns

• Workers as services. Keep the worker class thin: it should own the loop/polling contract only, and delegate actual work to injected domain services. This keeps it testable without booting the worker runtime.
• Tag, don't instantiate. Let the bundle's compiler pass collect workers by tag rather than new-ing them. This is the intended integration point and gives you container-managed dependencies (Doctrine, Monolog, HTTP clients) for free.
• Inject the manager, not the loop. In controllers and other services, inject the worker/manager service and dispatch jobs to it. The long-running loop should only ever live inside the console command/Symfony Console layer.
• Supervise outside PHP. Workers are daemons. Use supervisor or a systemd unit to restart on exit, and have the worker exit cleanly on SIGTERM/SIGINT so the supervisor can rotate it.
• Per-job isolation. For anything touching Doctrine, reset the EntityManager (and close/reconnect) between jobs — long-running processes accumulate identity-map state and stale connections.
• Logging channel. Route worker logs to a dedicated Monolog channel so you can filter daemon noise from request logs in production.

Gotchas and Tips

• Undocumented. With a badges-only README, 0 stars and 0 dependents, treat everything as "read the source before relying on it." Confirm the tag name, interface signatures and config alias by reading Compiler/, DependencyInjection/Configuration.php and the tests, not by guessing from the bundle name.
• Symfony version drift. The description explicitly says "Symfony2." Check composer.json constraints before dropping it into a Symfony 3/4/5 project — autoloading, bundle registration and container APIs changed. If you're on a modern Symfony, symfony/messenger is the maintained equivalent and probably the better choice for greenfield work.
• Maintenance risk. Zero stars and no release tags mean no upstream support. If you build on it, vendor a fork or pin the commit, and budget for owning the code.
• Silent tag failures. If your worker never runs, the compiler pass almost certainly didn't pick up the tag. Verify with app/console debug:container --tag=<tag> and confirm the service implements the exact interface the pass requires (including namespace).
• Memory leaks. Daemons that never exit will grow. Cap iterations (--max-jobs/--max-time) and let the supervisor restart, or call gc_collect_cycles() periodically.
• Graceful shutdown. Register signal handlers so in-flight jobs finish before exit; otherwise a supervisor restart can kill a job mid-transaction.
• Extension points. The compiler pass (custom worker registration) and the component's event dispatcher are the two hooks worth knowing — subscribe to worker events for metrics/alerting rather than instrumenting each worker individually.