Scheduler Queues Livewire Laravel Package

Getting Started

This is a presentation adapter, not a scheduler or queue implementation. It assumes the Liberu scheduler and queue domain modules are already installed; this package only supplies Livewire components/views that render their state. Plan to install it alongside those modules, not standalone.

composer require liberusoftware/scheduler-queues-livewire

Because it is part of the Liberu modular ecosystem, registration is usually not automatic in the way a normal Laravel package is. Check in this order:

1. composer.json → extra.laravel.providers — if absent, you must register the service provider manually in bootstrap/providers.php (Laravel 11+) or config/app.php.
2. The module manifest — Liberu projects typically gate modules behind a modules_statuses.json or a php artisan module:enable <Name> command. If the package's views render blank, this is the first thing to verify.
3. src/Livewire/ — this is the real API surface. Each class is a component; each render() points at a view under resources/views/livewire/. Read these two directories before anything else, because docs are likely absent.
4. config/ and any routes/web.php — determine whether routes are auto-registered or whether you are expected to mount components yourself.

First use case: drop the scheduler listing component into an existing admin layout:

<livewire:scheduler-queues.scheduled-tasks />
<livewire:scheduler-queues.failed-jobs />

(Confirm the exact aliases from the #[LivewireComponent] attribute, protected $alias, or Livewire::component() calls in the provider — do not guess.) Wrap in your own @can / Gate check before rendering; do not assume the package ships authorization.

Implementation Patterns

Mount it behind your own route, not the package's. A presentation adapter should not own your admin routing. Create a thin controller or Route::view() in your app, apply auth and an admin gate, and render the component inside your layout. This keeps upgrades from silently changing who can reach the dashboard.

Route::middleware(['auth', 'can:view-ops'])->get('/ops/queues', fn () => view('ops.queues'));

Poll for freshness, do not websocket it. Livewire's wire:poll.10s on the component root is the low-effort pattern. If the component exposes a refresh() method, call that instead of relying on a full re-render, and add wire:poll.visible so background tabs do not hammer the database. For queues with high throughput, poll failed/queued counts with a lightweight aggregate query rather than letting the component hydrate full job payloads.

Treat actions as delegation, not reimplementation. If the component exposes "run now", "retry", "delete", or "flush" actions, they should call into the underlying scheduler/queue services (or Artisan::call) — verify this by reading the action methods. If any action manipulates the jobs / failed_jobs tables directly, wrap it in your own service so you can swap the queue driver later without forking the view layer.

Override views rather than the component classes. Publish views and restyle in resources/views/vendor/.... Subclassing a Livewire component from a low-adoption package locks you to its internal property names, which are the most likely thing to change between releases.

Compose domain data via your own view composer. If you need extra columns (queue name, connection, tenant, duration), inject them through a view composer or a wrapper view instead of editing vendor Blade files, which will be overwritten on composer update.

Test the components with Livewire::test() using factories for Job/FailedJob rows. This is the cheapest way to discover what each component actually requires (which properties are mandatory, whether it lazy-loads, whether it respects pagination) without reading every line.

Pair it with an event listener for real-time signal. Queue::failing, JobProcessed, and ScheduledTaskFailed listeners that increment a counter or dispatch a broadcast are more reliable than polling if you need alerts rather than a dashboard.

Gotchas and Tips

• License is NOASSERTION. There is no declared SPDX license. Do not ship this into a commercial or redistributed product without confirming terms with the maintainer. This is a hard blocker, not a formality.
• Zero stars, zero dependents. Assume no community support and no Stack Overflow answers. Budget time to read the source. The release date metadata is future-dated relative to normal usage, which suggests automated/irregular releases rather than a curated changelog — pin an exact version ("liberusoftware/scheduler-queues-livewire": "x.y.z") and review diffs on upgrade.
• Livewire v2 vs v3 incompatibility. Component syntax, $listeners vs #[On], and wire:poll behavior differ. Check the composer.json constraint against your app's Livewire version before installing; a mismatch produces silent render failures or "component not found" errors rather than a clear exception.
• Queue driver introspection is not uniform. Database and Redis drivers expose failed jobs differently, and SQS exposes essentially nothing. Components that display or retry failed jobs may only work with database/redis. If retry appears to do nothing, verify the failed_jobs table exists and the connection in config/queue.php matches what the component assumes.
• Scheduler timezone drift. Laravel's schedule:list and the Schedule facade evaluate cron in the app timezone (config/app.php), while the UI may render UTC or server local time. "Next run" columns are the most common source of "the dashboard is wrong" reports. Confirm the component's formatting path.
• Blank component / no routes after install. Nine times out of ten the module is not enabled in Liberu's module status file, or the provider was not registered. Run php artisan about and php artisan vendor:publish --provider=... and check livewire:find or Livewire::getClass() to confirm the alias resolves.
• Polling + N+1. A naive wire:poll over a job list can issue a query per row if the component eager-loads relations lazily. Profile with Telescope/Debugbar before putting it on a wall-mounted dashboard.
• Long-running actions block the render. "Run task now" that synchronously executes a heavy job will hang the Livewire request. Prefer dispatching to a queue even for manual triggers.
• Authorization is your responsibility. Presentation adapters in this ecosystem frequently ship without gates. Add a policy around the route; do not rely on the component to check Gate::allows().
• Extension point is the underlying domain module, not this package. If you need behavior the UI does not provide, contribute it to the scheduler/queues module and let this adapter render it — forking the adapter is the wrong layer and guarantees upgrade pain.