Laravel Job Laravel Package

Getting Started

Install the package with Composer:

composer require mxl/laravel-job

Laravel’s package auto-discovery registers the service provider, so there is no config file to publish in the common case. Confirm the commands are available:

php artisan list | grep job

Look first at:

1. job:dispatch — the primary command; understand its argument and option shape (--connection, --queue, --delay).
2. job:list / job:watch — the queue inspection commands.
3. config/queue.php — this package reads the standard queue configuration; it does not replace it.

The first practical use case is firing a single job from a terminal without going through tinker or a REPL. A typical invocation is:

php artisan job:dispatch "App\Jobs\SendWelcomeEmail" --queue=emails

For jobs that take constructor arguments, pass the payload the way the command expects (JSON or option-based, depending on version), for example:

php artisan job:dispatch "App\Jobs\ProcessOrder" '{"orderId":1234}' --queue=orders

Then verify it landed with:

php artisan job:list --queue=orders

Implementation Patterns

Smoke-testing queue wiring. Before deploying, run job:dispatch against each queue you depend on, then job:list to confirm the connection and queue names are correct. This catches .env drift (wrong QUEUE_CONNECTION, wrong queue name) far earlier than watching a worker sit idle.

Deploy-hook dispatch. Use job:dispatch in a deploy script to kick off a single warm-up or cache-invalidation job after artisan migrate:

php artisan job:dispatch "App\Jobs\WarmProductCache" --queue=maintenance

Because it runs in the normal Laravel console context, it respects your environment config and APP_ENV at invocation time.

Structured JSON payloads for argument-heavy jobs. Keep job constructors accepting scalars or arrays, then dispatch them with a single JSON blob. This makes the command line a stable, scriptable interface:

php artisan job:dispatch "App\Jobs\Reindex" \
  '{"index":"products","ids":[1,2,3]}' \
  --queue=search --delay=30

Failed-job triage loop. Combine inspection with the package’s failed-job helpers:

php artisan job:list --failed
php artisan job:retry --queue=orders

Treat this as the operator’s loop for “something broke on the queue.”

Watch mode during development. Run a worker in one pane (php artisan queue:work --queue=orders) and job:watch in another to see enqueue/processing activity as you exercise the app.

Wrap it when payloads grow. If you find yourself shell-escaping large JSON blobs or repeated flag combinations, write a thin custom Artisan command that builds the job object directly and calls dispatch(). Keep job:dispatch for ad-hoc and CI use, and the wrapper for team-wide workflows.

Scheduler integration. For recurring or one-off maintenance jobs, prefer the Laravel scheduler with a job class rather than shelling out to job:dispatch; reserve the command for manual and deploy-time triggers where you want a visible, auditable action.

Gotchas and Tips

• The database queue driver is the happy path. job:list, job:watch, and job:forget need a queue backing store they can read. With the sync driver, dispatched jobs execute immediately and there is nothing to list; with Redis or SQS, visibility depends on the package version. Set expectations accordingly.
• Shell-escape the FQCN. Backslashes in "App\Jobs\Foo" are interpreted by the shell. Always quote the class name; on Windows/PowerShell the escaping rules differ again.
• Constructor arguments must be serializable primitives. Pass IDs, not Eloquent models. Passing an object graph through the command line will either fail to deserialize or silently produce a different object than dispatch(new Job($model)) would.
• job:clear and job:flush are destructive. Never wire them into a deploy script or an unsupervised cron. Gate them behind an explicit confirmation flag or a --force check in your own wrapper command.
• job:watch is polling, not event-driven. Very fast jobs can be enqueued and processed between polls and appear to vanish. Confirm with job:list and worker logs before assuming a dispatch failed.
• Failed jobs need the table. Run php artisan queue:failed-table && php artisan migrate before relying on job:retry; otherwise the failure operations no-op or error.
• Clear the package cache after upgrades. After composer update, run php artisan package:discover (and config:clear if you cached config) so Artisan picks up the commands.
• Environment mismatch on cron. A cron-invoked job:dispatch may run with a different APP_ENV or working directory than your interactive shell. Pin --env or cd into the project root in the crontab entry.
• The command does not bypass the queue. It dispatches; it does not execute. If you need synchronous execution for debugging, use --sync if supported, or dispatch through tinker with the sync connection explicitly.
• Extension point is the service provider. If you need different command signatures or stricter input validation, either subclass the package command and re-register it, or write your own command that composes the underlying job dispatch — don’t fork the package for small behaviour changes.