Worker Bundle Laravel Package

Technical Evaluation

Architecture fit — a category error before it is a technical one. The brief frames this as a Laravel/PHP package evaluation; fm/worker-bundle is a Symfony bundle (Treehouse Labs) and targets Symfony's kernel, bundle registration, and DI container. Laravel's service-provider/container contract is a different abstraction with different conventions. Any Laravel use would require us to author and own a bridge layer — service-provider wrapper, config translation, container aliasing — which is bespoke glue code with no upstream support. Even setting the framework mismatch aside, the package's own description states it is superseded by treehouselabs/worker-bundle. We would be standardizing on an artifact its maintainers have already routed away from.

Integration feasibility — low, and the feasibility question is the wrong one. Score 0, no stars, 0 dependents, no visible downstream usage. The observable capability is a worker/queue-daemon abstraction: worker definitions, process lifecycle (start/stop/restart), console + DI integration, and extension hooks for logging/monitoring. In a Laravel context that surface is already covered by the native queue worker plus Supervisor, or Horizon for Redis. So the honest question is not "can we wire it up" (probably yes, with effort) but "what capability does it give us that we do not already have, for free and maintained" — and the answer is nothing demonstrable.

Technical risk — elevated, concentrated in abandonment and unverifiability.

• Abandonment / supply chain: superseded packages get no security patches. Every future PHP floor bump or Symfony advisory becomes our fork to fix.
• Verification risk: zero dependents means no independent evidence that the lifecycle handling — signal handling, child reaping, graceful shutdown, restart-on-exit-code — behaves correctly under load. Forking/daemon code is precisely where subtle defects hide.
• Documentation risk: assume thin. Ramp-up is discovery-by-source-reading.
• Blast radius: a supervisor/lifecycle defect manifests as silently stalled jobs and growing backlog — high severity, low detectability, and it sits underneath everything else in the pipeline.

Key questions a TPM should force to closure before any spike is funded:

1. What specific capability did we believe this provides that Laravel's queue worker / Horizon / a managed queue does not?
2. Is there any internal usage today? Audit composer.lock and namespaces across all repos — 0 public dependents does not mean 0 internal.
3. Is treehouselabs/worker-bundle a drop-in successor (compatible API/config), and does it independently pass a maintenance and dependents check? Succession does not confer health.
4. Which queue backend do we actually run (Redis, SQS, RabbitMQ, database), and does it already have a first-class Laravel driver?
5. What are last-commit dates and open-issue counts on both the original and the successor?

Integration Approach

Stack fit — mismatch, and the recommendation is no integration. Our stack is Laravel/PHP; this is Symfony/PHP. PHP-version overlap is the only common ground. Bridging yields two container conventions, two config systems, and debugging paths no one on the team recognizes — a permanent cognitive and maintenance tax paid to avoid using the framework's native queue.

Migration path — treat this as an extraction, not an adoption. If we discover it in a lockfile, the correct framing is technical-debt retirement with a named owner and a date:

1. Inventory real usage: bundle namespace grep, composer.lock inspection, config tree references.
2. Map each worker/job definition to a Laravel Job class and a queue connection.
3. Stand up native queue workers under Supervisor (or Horizon if Redis) in parallel.
4. Dual-run in non-production; compare throughput, restart behavior, and failure modes.
5. Cut over per queue — never a single flag day — keeping the old worker definition as a rollback for one release cycle.
6. Remove the bundle and its transitive Symfony dependencies.

If a genuine capability gap is confirmed, evaluate the successor (treehouselabs/worker-bundle) or a maintained standalone library first — never the superseded artifact.

Compatibility. Symfony bundle version constraints (framework-bundle, PHP floor) will likely conflict with the Symfony components Laravel already pins (console, process, http-foundation). Expect Composer solver conflicts and potential forced downgrades of shared symfony/* packages — a change that ripples into unrelated Laravel internals. Validate with composer why-not before funding any spike; a downgrade cascade is a hidden cost that must be surfaced to stakeholders early.

Sequencing (TPM-owned plan).

1. Capability audit against native Laravel queue features — 1–2 days, one senior engineer.
2. Internal-usage audit across all repos and lockfiles — same window, parallel.
3. Decision gate: gap confirmed vs. not. Default outcome is "no gap."
4. If gap: timeboxed one-week spike of the successor, with an explicit written kill criterion and a named owner.
5. Either way: record the decision and rationale in the dependency register so it is not re-litigated next quarter.

Operational Impact

Maintenance. Effectively unmaintained upstream. Every future PHP upgrade, Symfony bump, or advisory in the transitive tree becomes our fork to patch. Forking is a permanent line item, not a one-time integration cost: we would inherit ownership of daemon/forking logic with no upstream expertise and no test-suite confidence. As TPM, budget it as ongoing headcount fraction, not a project task.

Support. No vendor, no SLA, no security-response path, no community, no internal expertise. The escalation path for a production incident is "read the source at 2 a.m." — unacceptable for infrastructure-tier code sitting underneath job execution. Contrast with Horizon: documented, widely deployed, observable, and already understood by every Laravel engineer we hire.

Scaling. Unverified. A process-supervising worker daemon scales by adding processes, which requires an external supervisor (Supervisor/systemd) regardless of package choice — so this package adds no scaling capability we would not otherwise need to build. Throughput ceilings, long-running memory behavior, and graceful-restart semantics are all unvalidated with zero downstream evidence. Do not assume parity with the native worker.

Failure modes to design against (only if adopted).

• Orphaned child processes after a parent crash → resource exhaustion and duplicate job execution.
• Silent backlog growth when the supervisor dies without alerting → jobs stop, nothing pages.
• Non-idempotent re-delivery on ungraceful shutdown → duplicated side effects.
• Hidden transitive Symfony downgrades → unrelated runtime breakage elsewhere in the application.
• No health endpoint → liveness/readiness probes must be built from scratch.

Ramp-up. Small code surface, high discovery cost: no docs, no examples, no prior art. Realistically 3–5 days for a senior engineer to reach working competence, plus a continuing tax on onboarding and code review. Marginal ramp-up for Laravel's native queue worker is approximately zero — every Laravel engineer already knows it, and Horizon adds a UI and metrics for free.

TPM recommendation. Do not adopt. Close the evaluation. Record "rejected: superseded upstream, zero dependents, Symfony/Laravel mismatch, no differentiated capability" in the dependency register, redirect the effort to Horizon/Supervisor hardening or a managed queue service, and open a migration ticket only if the internal-usage audit finds it in a lockfile. The deliverable of this evaluation is a documented, defensible "no" — that is a successful outcome, not a wasted cycle.