Mq2Php Bundle Laravel Package

Product Decisions This Supports

• Async architecture shape: "serialized callable" vs. "data + handler registry." The package embodies a specific design choice — putting a PHP callable (class/method/closure reference plus args) into the broker message and having the consumer call_user_func it. This is the core decision it informs, and it is the decision most worth deliberating rather than copying.
• Dynamic job dispatch without redeploys. If a roadmap item requires enqueuing work that isn't known at build time (tenant-defined workflows, plugin/extension actions, admin-triggered jobs), this pattern demonstrates the trade-off: flexibility gained vs. a whitelist/registry you now must govern.
• Build vs. buy for job serialization. For a Laravel codebase the answer is effectively "build on what we have." Laravel's queue already serializes job classes, Eloquent models (SerializesModels), and dependencies via the container — this package adds nothing there and is a Symfony bundle (FrameworkBundle service wiring), so "buy" means "adopt a second framework's idioms and a 2018-era dependency."
• Broker trust boundary. It forces an explicit product/security decision: is the message broker part of our trusted compute boundary? If a message can contain arbitrary PHP, then broker write access ≈ production code execution. That is a decision to make consciously, not incidentally.
• Use cases where the pattern legitimately applies: internal-only Symfony + RabbitMQ systems, batch/ETL orchestration, and sandboxed plugin executors with a hard allowlist of Class::method targets.

When to Consider This Package

Adopt only if all of the following hold:

• The service is Symfony, not Laravel (this is a bundle; there is no Laravel service provider and no illuminate/* support — you would be reimplementing the wiring).
• The broker is fully trusted and network-isolated, and messages are not writable by tenants, third parties, or unsanitized user input.
• You specifically need closure/callable dispatch, not just class-based jobs, and you can constrain it to an allowlist.
• You accept a dependency frozen at 2018-01-29, with 1 star, 0 dependents, no PHP 8 support guarantees, no security response process, and no release cadence. That means owning the fork.

Look elsewhere — or build ~150–300 lines in-house — when:

• You are on Laravel: use the native queue with job classes and SerializesModels. It is maintained, observable (Horizon/Telescope), retry/backoff-aware, and does not execute broker-supplied code.
• You need maintained dependencies, PHP 8.x, static analysis, or a CVE path. A 1-star, 0-dependent package is a supply-chain and audit liability, not a foundation.
• You need observability, dead-letter handling, idempotency, or schema evolution for messages — none of which this package addresses.
• Your broker is multi-tenant or externally writable. Executing serialized PHP from a message is a remote-code-execution surface; the risk is not theoretical and does not scale down with the package's popularity.

How to Pitch It (Stakeholders)

To executives: This package lets a queue consumer execute PHP code carried inside the message. It has 1 GitHub star, zero dependent projects, and no release since January 2018 — there is no maintainer, no security patching, and no support path. It is also built for Symfony, while we are on Laravel, so adopting it means owning a fork of an abandoned library to gain a capability our framework already ships. Recommendation: do not adopt; treat as a reference design only. Our exposure if we adopted it would be an unaudited code-execution path behind our message broker — the highest-severity class of vulnerability — in exchange for zero unique capability.

To engineering: Laravel's queue already serializes job classes and model identifiers to the broker and resolves handlers on the consumer. The only thing this bundle offers beyond that is dispatching arbitrary callables, which is precisely the part we should not want. If we have a real need for runtime-defined work (tenant workflows, plugin actions), we should implement a handler registry: messages carry a stable action key plus a JSON payload, and a config-driven map resolves the key to a class. That gives us the same flexibility, an explicit allowlist, schema versioning, and no third-party dependency — roughly a sprint's worth of work, fully testable, and it keeps the broker out of our trusted compute boundary. Action: close this out as evaluated-and-rejected; file the registry pattern as a spike if the dynamic-dispatch requirement is confirmed.