Laravel Queue Autoscale Laravel Package

Product Decisions This Supports

• Feature/roadmap: making "bring your own queue driver" a supported story. Until now the package judged a connection by its driver name, so anything registered via Queue::extend() was invisible to the package's core logic. That is a quiet but real ceiling on the addressable market: teams that wrap SQS/Redis/Database to add prefixing, tenancy, encryption, or observability were getting wrong answers rather than no answers. v4.6.1 is the roadmap item that turns that from "unsupported, file an issue" into "supported, judged by what it extends."
• Build vs buy. Driver introspection across four built-in queue families (background, sync, deferred, null, SQS, Redis, Database) plus a documented fallback when resolution fails is exactly the long-tail correctness work an in-house autoscaler accumulates and never finishes. This release is a concrete data point for the "buy" side of the argument.
• Use cases now correctly served: workload attribution (a subclass of SyncQueue no longer appears as jobs no worker can run — i.e., phantom backlog that misleads capacity planning); autoscaling decisions on Redis/Database subclasses (previously treated as unable to report oldest-job age, causing false "no signal" or premature scaling); SLA/breach reporting (recovered queues no longer held as breached); and queue:autoscale:doctor SQS diagnostics — dotted queue names and missing SLA signal — firing for SQS subclasses instead of being silently skipped.
• A product decision about honesty of output. The failure mode fixed here is not a crash; it is a dashboard that confidently reports the wrong thing. For a tool whose entire value is "tell me whether to add or remove workers," that is the highest-severity class of bug. Worth stating explicitly in release comms as a correctness release, not a features release.
• Deployment decision, not a code decision. Upgrading needs no config changes but does require restarting every queue:autoscale process. The manager now holds one resolved instance of each custom-driver connection open for the process lifetime. That is a coordination item for the rollout checklist and a thing to note for teams running many long-lived autoscaler processes against many custom connections.

When to Consider This Package

Consider it when:

• You run Laravel queues in production and sizing (worker count) is currently a static, hand-tuned or cron-guessed number.
• You are on SQS, Redis, or Database — or on a custom driver that extends one of those, which is now the supported path.
• You want per-queue backlog and oldest-job-age signal feeding autoscale decisions rather than a separate metrics stack you have to keep aligned with your queue config.
• You maintain custom Queue::extend() drivers. This is the release that makes the package usable for you; anything earlier should be considered unreliable in your environment.
• You need a pre-flight diagnostic (queue:autoscale:doctor) that respects your custom driver's characteristics.

Look elsewhere when:

• Your queue backend is a broker that does not extend a built-in Laravel queue. Resolution will fail and the package falls back to judging by driver name — the pre-4.6.1 behavior. That is a graceful degradation, not a fix; treat non-extending custom brokers as unsupported until proven otherwise.
• You are not on Laravel queues, or you run a polyglot fleet where autoscaling has to be decided outside the PHP process.
• You cannot tolerate a persistent resolved connection per custom driver for the process lifetime (long-lived processes, many tenants, strict connection-count budgets).
• You need the autoscaler to survive broker outages with fresh resolution — a failed resolution is cached until process restart by design.

How to Pitch It (Stakeholders)

For executives: This is a correctness release for the autoscaler, and it closes a gap that limited who could use it. Customers running customized queue connections were previously getting wrong capacity signals — queues that looked busy but had no runnable work, or queues that looked unhealthy after they had already recovered. Those failure modes cost money in both directions: over-provisioned workers, and SLA breaches reported against healthy queues. There are no configuration changes and no API breakage; the upgrade cost is a coordinated restart of the autoscaler processes, which is a routine deployment step rather than a migration. It expands the set of customers we can credibly sell to, at patch-release risk.

For engineering: v4.6.1 resolves a connection's built-in queue family once per process and judges it by what it extends, rather than by driver name. Subclasses of BackgroundQueue, SyncQueue, DeferredQueue, NullQueue, SqsQueue, RedisQueue, and DatabaseQueue now behave as their parents across workload reporting, queue:autoscale:doctor, the engine, the cluster summary, and the console. Built-in drivers are untouched and are never resolved. Resolution failure (broker down, missing credentials) degrades to name-based judgement and is not retried until restart. New public surface: Support\QueueDriver::of(). Test suite validated against cboxdk/laravel-queue-metrics 3.5.1 (JobMetricsRepository::listJobs()); test-only, no runtime impact. Action item: add "restart all queue:autoscale processes" to the upgrade runbook, and be aware of one held connection instance per custom driver per process.