“Replay/Retry jobs” & advanced search in Horizon (local/dev only)

[ZlatanOmerovic]

Context

Horizon is central to our workflow. During development we often need to re-run the same job payload (successful/silenced/failed) to debug, profile, or iterate without re-triggering the app flow or crafting ad-hoc Artisan calls.

Problem

Today, re-executing a specific historical job (with its original payload) from Horizon requires manual work: re-hitting app endpoints, writing one-off seeders/commands, or copy-pasting JSON into queue:push. Similarly, finding jobs across queues/classes/IDs is slower than it could be—Horizon shows recent jobs but lacks focused filtering across queue name, job FQCN, and job UUID/ID.

Proposal (two parts)

1) “Replay/Retry job” actions (local/dev only)

• Actions in UI: Add per-job actions in the Job detail view:
  • Replay – enqueue the exact original payload and options (connection, queue, delay, maxTries, etc.).
  • Retry – behavior identical to Horizon’s existing “Retry” for failed jobs, but enabled for any job status (processed/silenced/failed), re-queuing the same payload.
• Scope gating: Actions visible and enabled only when app()->environment('local', 'development') or a Horizon config flag is set.
• Replay source of truth: Use the serialized command/payload stored in Redis (the same blob Horizon shows in the Job detail) to create a new queued job entry. Do not mutate historical records.
• Audit note: Add a small banner “Replayed at {timestamp} by {user}” in the new job’s metadata (local only) to distinguish from organically queued jobs.

Example config

// config/horizon.php
'dev_tools' => [
    'enable_replay' => env('HORIZON_ENABLE_REPLAY', true),
    'enable_retry_for_all_statuses' => env('HORIZON_ENABLE_RETRY_ALL', true),
    'guard' => 'web', // guard used to authorize UI actions
],

Server-side guardrails:

// AppServiceProvider or HorizonServiceProvider
Horizon::auth(function ($request) {
    return app()->environment(['local','development'])
        && optional($request->user())->can('use-horizon-dev-tools');
});

// Optionally hard-gate the endpoints as well:
if (app()->environment(['local','development'])) {
    Horizon::routes(); // register extended dev routes
}

HTTP endpoints (concept):

POST /horizon/api/jobs/{id}/replay   // re-enqueue using stored payload
POST /horizon/api/jobs/{id}/retry    // allow for any status in local

Acceptance criteria:

• From Job detail, user can click Replay or Retry; a new job appears in “Pending” with same payload & options.
• Works for jobs with status: processed, failed, or silenced.
• Feature only renders & functions in local/dev, or when explicitly enabled via config.
• No changes to historical job entries.

2) Search & filter across jobs

• Global search bar at top of Jobs page with filters:
  • queue:payments (by queue name)
  • class:App\Jobs\ChargeCard (by FQCN; support short class:ChargeCard alias)
  • id:UUID (by job UUID)
  • Free-text matches inside payload JSON (optional, best-effort)
• UI facets: Dropdowns for “Queue”, “Status”, “Time range”; text input for “Class” and “ID”.
• Pagination: Use existing Redis indices; where absent, build lightweight secondary indices (below).
• APIs (concept):

  GET /horizon/api/search?queue=&class=&id=&status=&since=&until=

• Indexing (implementation note):
  • Maintain small Redis Sets/SortedSets:
    • horizon:idx:queue:{name} -> jobIds
    • horizon:idx:class:{fqcn} -> jobIds
    • horizon:idx:status:{processed|failed|silenced|pending} -> jobIds
  • Populate on write paths Horizon already controls (when job is recorded), bounded by Horizon’s retention config.

Acceptance criteria:

• Filtering by any of: queue name, FQCN, job UUID/ID returns matching jobs within configured retention window.
• Composable filters (e.g., queue + class + time range).
• Zero performance impact on production paths; the indices respect retention and are optional if disabled.

UX sketch (textual)

• Job detail header: [ Replay ] [ Retry ] (buttons), disabled when not in local/dev.
• Jobs list: Search input with inline chips:
  • Type queue:emails class:App\Jobs\SendMail since:-2h
  • Press Enter → results update, chips render; X to remove.

Security & safety

• Actions only available when APP_ENV ∈ {local, development} or enabled via HORIZON_ENABLE_REPLAY env.
• Routes are auth-gated via Horizon::auth and can be additionally protected by a specific permission.
• Endpoints return 403 outside allowed environments.
• Replay never mutates history; it creates a new enqueue with clear provenance.

Alternatives considered

• Ad-hoc Artisan commands (queue:push, tinker) – flexible but slower and error-prone.
• App-level “debug endpoints” – leaks concerns into application layer, not ideal.

Why this fits Horizon

• Debugging queues is a core Horizon use case; “Replay” and better search reduce friction without affecting production stability.
• Local-only behavior + config gates keep prod risk at zero.

Happy to contribute a PR implementing the UI, routes, and minimal indices if maintainers agree on approach and naming.