Challenge 3: Diagnose a Silently Stuck Queue — Possible Solution
====================================================================

TWO POSSIBLE CAUSES, AND HOW TO CHECK FOR EACH
--------------------------------------------------

CAUSE 1: No queue worker is actually running.

  ProcessOrder::dispatch($order) succeeds regardless of whether anything
  is listening to consume jobs from the queue — dispatching just writes
  a job record to the configured queue backend (a database table or
  Redis list); nothing REQUIRES a worker to be running for that write to
  succeed. If no worker process is running, jobs simply accumulate
  indefinitely with no error anywhere pointing at the cause.

  HOW TO CHECK:
  - Run `php artisan queue:work` manually in a terminal and watch for
    output — if a previously "stuck" job immediately starts processing
    the moment the worker starts, that confirms no worker was running
    before.
  - Check the jobs table directly (if using the database queue driver):
      SELECT COUNT(*) FROM jobs;
    A non-zero, growing count with no worker output in the logs strongly
    suggests jobs are piling up unconsumed.
  - In production, confirm whatever process manager is supposed to be
    keeping `queue:work` running (Supervisor, systemd, Laravel Horizon)
    is actually configured and active — a worker that crashed and wasn't
    automatically restarted produces this exact symptom.

CAUSE 2: QUEUE_CONNECTION is accidentally set to sync (or something
  unexpected) in the relevant environment.

  If QUEUE_CONNECTION=sync, dispatch() doesn't queue the job at all — it
  runs handle() immediately, synchronously, in the same request. This
  wouldn't cause jobs to pile up unconsumed (the opposite problem — jobs
  never actually queue, they just run inline), but it's worth checking
  because it means .env's queue setting doesn't match what was assumed;
  if the ORDER CONFIRMATION step specifically depends on being processed
  by a worker with different permissions/environment/timing than the web
  request itself, a sync-mode job silently behaving differently (or
  failing due to missing worker-specific configuration) could look like
  "processing never happens" even though the job technically "ran."

  HOW TO CHECK:
  - Run `php artisan config:show queue` or check .env directly for the
    current QUEUE_CONNECTION value in the actual environment being
    tested.
  - Compare it against what's expected for that environment — local
    development commonly defaults to sync (or database), while
    production should be pointed at a real backend like redis or
    database with an actual worker process running continuously.

WHY THIS WORKS
--------------
- Both causes produce the SAME visible symptom from the user's
  perspective — "order processing never seems to happen" — which is
  exactly why diagnosing a queue problem requires checking the
  infrastructure (is a worker running? what's the actual queue driver?)
  rather than assuming the job's own code (handle()) is at fault.
- This mirrors precisely the debugging instinct the Django course's
  Celery chapter taught: a queued task that never runs is very often not
  a bug in the task itself, but a missing or misconfigured worker process
  — the same category of problem, independent of which framework's queue
  system is involved.