Symfony Spawn Laravel Package

Getting Started

symfony-spawn is a pre-1.0 process/thread spawning helper for Symfony-flavored apps, and in Laravel it's most useful as an escape hatch for parallelizing I/O-bound work (HTTP fan-out, cache warmup, batch warmers) or for booting a multi-worker HTTP server without pulling in Octane. Start by reading the README and the src/ entry points for the Spawn/runner class and HttpServerConfig, then install with composer require yangusik/symfony-spawn and confirm the installed version (composer show) — v0.2.3 changed how the worker pool is configured.

First practical use case: parallel cache warming. Register a small artisan command that fans out closure-based work across the pool, runs it once during deploy, and exits. If you're using the HTTP server path, configure the pool through HttpServerConfig::setWorkers() and verify worker count and boot behavior on a staging box before touching production.

Because there's no prior assessment and this is a 0.2.x release, treat the public API as unstable and pin an exact version in composer.json until 1.0.

Implementation Patterns

Worker pool via HttpServerConfig::setWorkers(). As of v0.2.3 the pool is driven through HttpServerConfig::setWorkers() rather than ad-hoc worker counts. Set it in a service provider or a dedicated bootstrap file, keep the value in config/ (env-backed), and avoid scattering worker counts across the codebase.

Closure-based fan-out. The multi-threaded runner now correctly handles thread closures, so the idiomatic pattern is: build a list of small closures (one unit of work each), hand them to the runner, collect results. Keep each closure short and self-contained — one HTTP call, one cache key, one file operation.

Cache warmup as a phase, not a side effect. v0.2.3 explicitly fixes cache warmup, so treat warmup as a named step: warm → verify → serve/process. Don't interleave warmup with request handling; you'll hide failures and reintroduce the cold-cache path in production.

Wrap it in an artisan command. For batch use, an artisan command with a --workers option that maps to the pool size is the lowest-friction integration. It's testable, schedulable, and easy to run in deploy scripts. Avoid calling spawn directly from controllers — request-scoped state and forked workers don't mix well.

Fail loudly per worker. Collect exceptions per closure and report an aggregate result. A silently dying worker looks identical to a fast one; log worker index, closure label, and duration.

Pin and upgrade deliberately. This is the second bugfix release in a row touching the runner and config surface. Follow the changelog between 0.2.x versions, run the pool path in CI (even a smoke test with two workers), and re-read HttpServerConfig after each bump.

Gotchas and Tips

• 0.2.3 is a config-breaking refactor in practice. setWorkers() now drives the pool; any code that set worker counts elsewhere in 0.2.2 needs auditing. Grep for worker-count config before upgrading.
• Thread closures and captured state. Closures that capture container-bound objects ($this->app, Eloquent models, request objects) are the classic failure mode. Pass scalars or IDs into the closure and re-resolve inside the worker.
• Laravel's container is not thread/fork-safe. Don't resolve services, open DB connections, or touch the session/cache facade from inside a worker without re-initializing. Prefer raw clients or reconnect-per-worker.
• Cache warmup ordering. Warm caches before serving traffic and before dispatching work that assumes warm caches. If warmup fails, fail the deploy rather than serving cold.
• Pre-1.0 semver. Minor bumps can break you; use exact pins ("x.y.z") and read the diff, not just the changelog headline.
• Debugging. When the pool hangs, reduce to one worker and one closure; if that works, the issue is shared state or a closure that never terminates. Add per-worker timeouts and a heartbeat log.
• Overlap with Octane/queues. If you already run Octane or Horizon, this package overlaps in scope. Don't stack process managers; pick one per responsibility (HTTP serving vs. background work).
• No first-class Laravel facade. Expect to write a thin wrapper (service provider + config + command) yourself; budget for that rather than assuming framework-native integration.
• Extension point to watch: the runner/config classes are where upstream is actively fixing bugs. Keep your wrapper thin so upstream changes stay a one-file edit.