- How do I install mpbarlow/laravel-queue-debouncer in a Laravel app?
- Install it with Composer and rely on Laravel package auto-discovery. Apply the package's trait or middleware to an existing queued job, usually starting with one or two jobs as a pilot. No schema changes or new infrastructure are required.
- Which Laravel versions does laravel-queue-debouncer support?
- Version 3.2.0 is described as a compatibility-only minor release that adds Laravel 13 support, with no new features or documented breaking changes. Do not assume older Laravel majors are still covered just because the changelog is additive. Verify the composer.json illuminate constraints, PHP floor, and CI matrix for Laravel 10, 11, and 12 before upgrading or adopting.
- How does debouncing queued jobs work in this package?
- The package suppresses duplicate queued jobs within a debounce window, typically by holding dispatches behind a cache-backed lock or cooldown key. When rapid repeated dispatches occur, only the latest job in the window is processed. This prevents queue flooding and duplicate work without requiring a custom event pipeline.
- Do I need to change my database schema to use laravel-queue-debouncer?
- No, the package does not require schema changes. Any persisted state is limited to cache keys used for debounce or lock behavior, and those keys expire naturally. Namespace those keys so they do not collide with application cache entries.
- Which cache driver should I use for reliable queue job debouncing?
- Debounce correctness depends on the cache backend's atomic lock behavior, so the cache store matters. Redis, Memcached, and DynamoDB do not behave the same as file or array stores, and the array store in tests will not expose production contention. Test against the cache driver you actually run in production.
- Is laravel-queue-debouncer a replacement for Laravel ShouldBeUnique or WithoutOverlapping?
- No, those native primitives solve idempotency and mutual exclusion, but they do not collapse a burst of N events into one trailing job. This package fills that specific gap and is best treated as an ergonomic wrapper around cache-backed lock behavior. Evaluate it alongside, not instead of, your existing uniqueness and overlap strategy.
- What happens with high concurrency or a database queue plus database cache?
- Debounce behavior depends on atomic lock semantics, so validate lock contention under worker concurrency before committing. A Redis and Horizon setup is the cleaner fit, while a database queue with database cache is the combination most likely to surprise you. Run a pilot on the real production stack rather than relying only on test defaults.
- How should I test laravel-queue-debouncer before production rollout?
- Apply the trait to one job behind a config flag or environment guard, then compare duplicate-execution counts before and after. Exercise the job with the production cache driver and realistic worker concurrency. The integration is additive and reversible, so removal is just a trait deletion plus a Composer remove.
- Can debounce keys collide across tenants or different job payloads?
- There is no upstream guarantee that debounce key derivation matches your tenancy model or job-payload expectations. Key collisions across tenants are a plausible silent bug class if keys are not namespaced carefully. Review and validate the key derivation for multi-tenant applications before relying on the package broadly.
- Is laravel-queue-debouncer actively maintained and what if it is abandoned?
- The project has a single primary maintainer plus a first-time drive-by contributor on the Laravel 13 compatibility release. The package is small enough to fork and vendor if it is abandoned, which materially caps the bus-factor risk. Review composer.json diffs and the PR #21 surface rather than assuming a compatibility release only changed constraints.