Proposal: Add --on-queue Option to queue:retry Command

[jaap]

We recently ran into a real-world deployment scenario that exposed a limitation in the current queue:retry command.

Our setup:

• Separate deploy pipelines for web and worker servers.
• During major refactors, we sometimes deploy workers ahead of the web, so new worker code needs to handle jobs produced by both the old (v3) and new (v4) web codebases.
• Both environments share the same queues during a short “grace period” — which can cause failed jobs when incompatible payloads land on the wrong worker version.

To mitigate this, we often need to manually recover or debug failed jobs from production by retrying them in a controlled environment (e.g. a v4 worker only).

Currently, php artisan queue:retry can re-queue a failed job, but only to its original queue. To work around this, we’ve been manually editing the failed_jobs table — changing the queue name before retrying — which is obviously not ideal.

A small addition would make this workflow much cleaner:

php artisan queue:retry {id} --on-queue=debug

This would retry the failed job, but re-enqueue it on a different queue (e.g. debug, v4, or manual_recovery) instead of the original one.

Why this is useful:

• Allows you to land on a queue without a worker and then manually execute on a server of choice running php artisan queue:work --queue=debug
• Helps when debugging failed jobs in production safely, without interfering with active workers.
• Enables smoother phased or versioned deployments of workers and producers.
• Provides a clean alternative to direct DB manipulation.
• Makes Laravel’s queue tooling slightly more flexible with essentially no breaking changes.

I’m happy to look into implementation details and submit a PR if there’s interest.

[macropay-solutions]

We are doing this in the code by creating a new message instead of retrying. Advantages of not relying on the framework.