- Can I install krlove/async-service-call-bundle in a Laravel application?
- No. This is a Symfony bundle: it registers through Symfony's kernel, hooks into the DI container and compiler passes, and dispatches through Symfony Messenger, none of which exist in a Laravel app. There is no supported interop path short of running a parallel Symfony kernel, which is not a reasonable trade for a package with no adoption signal. If you need the behaviour in Laravel, treat the bundle as a design reference and build the equivalent on Laravel's queue and container primitives.
- What problem does this bundle actually solve?
- It lets you mark a service method as asynchronous so that calling it no longer blocks the request cycle. Instead of executing the method inline, the call serializes the arguments, publishes a message to a queue, and returns immediately while a background worker performs the real work. It is aimed at slow side effects such as sending email, calling third-party APIs, or generating reports, where the caller does not need the result to render a response.
- How does the automatic proxy generation work under the hood?
- The bundle uses Symfony's DI container to decorate your service with a generated proxy class that implements the same interface. The proxy is produced by a compiler pass, so your existing constructor injection and type hints keep working unchanged. When a proxied method is invoked, the proxy marshals the arguments into a message, hands it to the configured transport, and returns without waiting for the underlying method to run. No manual message classes or handler wiring are required on your side.
- Which message queue transports are supported?
- Transport is pluggable, and the bundle delegates delivery to the configured queue rather than shipping its own broker client. In practice you point it at a Symfony Messenger transport such as AMQP, Redis, Doctrine, or a synchronous transport for testing. The durability guarantees you get are exactly those of the transport you configure, so pick one whose delivery and acknowledgement semantics match how much you care about losing a deferred call.
- Which PHP and Symfony versions does it support?
- That has to be verified against the package's composer.json before any decision, because there is no visible release or maintenance cadence to rely on. The repository shows no stars, no dependents, and no community backstop, so version constraints are effectively whatever the last commit left behind. If your application runs a current PHP or Symfony release, assume you would be the one adding support for it.
- How are exceptions and failed async calls surfaced to the caller?
- They are not surfaced to the caller, which is the defining trade-off of async method proxying. Because the call returns before the work executes, any exception is thrown inside the worker and lands in worker logs and whatever failure transport you have configured. You need retry and dead-letter handling plus alerting on the Symfony Messenger side, and you must decide per call site whether silent failure is acceptable to the business.
- Does the proxy preserve return types and type hints for static analysis and IDEs?
- Not in a way you can rely on. The call site no longer reflects what actually executes, so return values are unavailable, IDE navigation jumps to generated proxy code, and static analysis tools cannot follow the real control flow. Type hints and interface contracts are kept for injection purposes, but the semantics of a method that used to return a value change silently. Expect debugging, stack traces, and refactoring to get noticeably harder in exchange for the latency win.
- Is this bundle production-ready and actively maintained?
- There is no evidence that it is. Zero stars, zero dependents, no visible maintainer activity, and no adoption stories mean no production track record and no community to fall back on when something breaks. Adopting it would make your team the de facto maintainer of code you did not write, on the request path, with no upgrade story. That risk profile is the main reason to avoid it as a dependency regardless of how good the underlying idea is.
- What is the Laravel equivalent of calling a service method asynchronously?
- The idiomatic answer is a queued job: dispatch a job class from your controller or service and let a worker handle it through Redis, SQS, or the database driver. If you want to keep the service interface intact, wrap the service in a small decorator that dispatches the job and returns a handle instead of a result. Either way you inherit retries, backoff, failed-job handling, and Laravel Horizon observability that you would otherwise have to build around this bundle.
- How do I test code that dispatches async service calls?
- Configure a synchronous transport or fake the queue in your test environment so the work runs inline rather than in a separate worker. Then assert that the expected message or job was dispatched with the right serialized arguments, and separately test the underlying method directly since it now runs in isolation. In Laravel you would use Bus::fake or Queue::fake for the same purpose, which keeps assertion helpers first-class instead of hand-rolled.