Weave Code
Laravel Queue Batch Retry Laravel Package
kirschbaum-development/laravel-queue-batch-retry
Retry failed jobs in Laravel queue batches with a simple artisan command. This package re-dispatches failed batch jobs while preserving batch context, so you can recover from failures without manually tracking or re-queuing individual jobs.
Package to retry failed jobs in batch using custom filters
Frequently asked questions about Laravel Queue Batch Retry
- How do I install and set up laravel-queue-batch-retry?
- Install it with composer require kirschbaum-development/laravel-queue-batch-retry. The package uses Laravel package auto-discovery, so no service provider registration is needed. It adds no migrations or config file; it registers an Artisan command that works against the native job_batches and failed_jobs tables.
- How do I retry only specific failed jobs in a Laravel batch?
- Use the package's Artisan command to re-dispatch failed jobs that belong to an existing Bus::batch(). It is intended for operator recovery when you want a filterable blast radius instead of manually copying UUIDs from failed_jobs and re-queuing by hand. Scope it as ops tooling, not application code.
- What exactly do --filter and --exclude-filter match against?
- The release notes do not document whether --filter and --exclude-filter match job class, batch name, queue, connection, or a substring of those values. Verify the matching rules in the package source and confirm them against a staging batch before using the command in production. Treat the flag names as hints, not specifications.
- Can --filter and --exclude-filter be combined, and which wins on overlap?
- Both flags appear designed for a single invocation, but precedence on overlapping matches is not documented. Establish from source which filter wins when a job matches both include and exclude criteria. Test the overlap case explicitly on staging, because an over-broad exclusion can silently skip the one job that needed to run.
- Is there a --dry-run option to preview which jobs will be retried?
- A dry-run, verbose mode, or selection count is not documented in the available release notes. Check the command's help output and source for any preview capability before assuming one exists. If none exists, rehearse the exact command against a staging batch and confirm the selection size before touching production.
- How is this different from Laravel's built-in queue:retry-batch command?
- Laravel core provides queue:retry-batch; this package's differentiator is custom include and exclude filtering. If you do not need filters, prefer the core command and take the smaller risk. Adopt this package only when the filterable blast radius is worth the extra surface area.
- Will retrying failed jobs preserve the batch context and then/catch/finally callbacks?
- The package claims to preserve batch metadata and then, catch, and finally callbacks when re-dispatching failed jobs. The edge case to verify is an empty or fully excluded selection: if the batch never reaches a terminal state, downstream bookkeeping such as status flags, notifications, and cleanup may silently never run. Test that scenario explicitly.
- Is the retry command idempotent if I run it twice?
- Idempotency is not documented, so assume running the command twice may re-dispatch jobs that were already retried. That creates a real double-dispatch hazard during an incident. Verify behavior from source and staging, and guard production runs with a clear selection and a single operator.
- Is it safe to run in production alongside Laravel Horizon?
- Retrying is a mutating write against live queue data, so an over-broad selection can flood workers and duplicate customer-visible side effects. Running it alongside Horizon or core retry commands creates multiple paths to the same mutation, the exact condition that produces double-dispatches under stress. Use one recovery path at a time and coordinate with whoever owns the queues.
- Is laravel-queue-batch-retry actively maintained, and which Laravel and PHP versions are supported?
- Project health is thin: roughly 51 stars, zero dependents, a single maintainer plus one drive-by contributor, and a last release on 2024-06-11. It will probably lag future Laravel majors, so check composer.json and CI for the supported Laravel and PHP matrix before adopting. It is reasonable as ops tooling off the deploy path but not as a hard runtime dependency.
Weaver
How can I help you explore Laravel packages today?