- How do I install kregel/nova-failed-jobs-tool in a Laravel Nova app?
- Install it with Composer using composer require kregel/nova-failed-jobs-tool, then register the tool in NovaServiceProvider::tools() on Nova 3 or NovaApplicationServiceProvider::tools() on Nova 4 and newer. There are no migrations or required environment variables, and config publishing is optional. Because the last tagged release is from August 2021, verify the registration code against your installed Nova version before deploying.
- Does this package support Laravel 9, 10, 11 and Nova 4 or 5?
- There is no documented or tested support matrix beyond the Laravel 8 and Nova 3.3 era in which the last release shipped. Nova 4 changed tool bootstrapping, menu registration and front-end asset conventions, so compatibility is not guaranteed even though the tool may still load. Treat Nova 4 as unverified and expect Nova 5 to require a fork or patches. Pin a commit and test in staging before relying on it.
- Which failed job drivers does this Nova tool work with?
- It targets Laravel's database-backed failed job provider, so failed.driver must be set to database and records must exist in the failed_jobs table. Setups backed by DynamoDB or teams that only inspect failures through Horizon and Redis are not covered. If you use Horizon, its built-in failed job interface is maintained and generally the better choice.
- How do I retry or delete a failed job from the Nova interface?
- The tool provides retry and delete actions per failed job, mirroring Laravel's queue:retry and queue:forget behaviour. Retrying re-enqueues the stored payload against the connection and queue recorded in that payload, so a queue or connection that no longer exists will fail again. There is no documented auditing of these actions, so restrict access to trusted operators.
- Does it handle the uuid primary key and batched job payloads in failed_jobs?
- Laravel 9 and later changed the failed_jobs schema to use a uuid column and moved batch metadata into the payload, and this package predates those changes. Handling of uuid keys and batched payloads is untested and may break rendering or actions. If your app uses batches or the newer schema, plan to patch or fork the tool.
- Why does the tool error when rendering failed jobs after I renamed or deleted a job class?
- The tool must unserialize stored job payloads and render exception details, so payloads referencing classes that no longer exist will throw during rendering. That is exactly the situation where you most want visibility into the failure, which makes the failure mode especially frustrating. Keeping old job classes as stubs or patching the deserialization path are practical workarounds.
- Is it safe to expose failed job payloads in the Nova admin panel?
- Serialized payloads and exception traces routinely contain customer data, API tokens and PII, and the tool's only documented boundary is whatever gate already protects Nova access. There is no described per-resource policy, redaction or field-level authorization. If you install it, restrict Nova access tightly, consider network-level controls and review what your jobs actually serialize.
- Is kregel/nova-failed-jobs-tool still maintained?
- No. The last tagged release is from August 2021, the repository has around 14 stars, zero dependents and a single maintainer. That is hobby-grade rather than a maintained dependency, and the main risk is abandonment rather than complexity. Assume no upstream fix path for Nova major-version breakage.
- What should I do if the maintainer archives the repository?
- The codebase is small, so forking to an internal namespace, pinning the upstream commit and adding your own composer.json constraints against your Laravel and Nova versions is realistic. Treat it as vendored operator tooling you own rather than an external dependency. Add tests around payload deserialization and the retry and delete actions before relying on it.
- Why is the failed jobs list slow on large failed_jobs tables?
- The tool paginates directly against the failed_jobs table, and there is no index on failed_at by default in many applications. With a large backlog, pagination and sorting queries become slow. Adding an index on failed_at, or pruning old failures with queue:prune-failed, will improve responsiveness more than anything the tool itself does.