If a Laravel queue job runs twice after deployment, first determine whether the application dispatched two jobs or the queue redelivered one job. The common causes are a worker timeout that is not safely below retry_after, an SQS visibility timeout shorter than the real job duration, duplicate worker managers, an exception after an external side effect, or producer code that fires twice. Do not start by increasing retries.
Contents
Why can one repeated job become a business incident?
A repeated queue job may send the same email twice, decrement inventory twice, issue duplicate notifications, create another shipment, repeat a webhook call or attempt the same payment-side operation. The visible symptom appears in Laravel, but the cost is usually operational: staff reconcile records, customers lose confidence and downstream systems disagree.
The safe design question is not only “How do we stop the second run?” It is also “If delivery happens again, will the business operation remain correct?” Amazon SQS documents an at-least-once delivery model for standard queues and tells consumers to be idempotent because the same message can be received more than once. Review the AWS at-least-once delivery guidance.
Which nine checks explain why a Laravel queue job runs twice?
| Check | Evidence to collect | Likely action |
|---|---|---|
| 1. Count dispatches | business key, payload ID and dispatch timestamp | trace controller, event, listener, scheduler or webhook |
| 2. Compare timeout values | job duration, worker --timeout, retry_after |
keep worker timeout several seconds shorter |
| 3. Check SQS visibility | queue visibility timeout and slowest valid runtime | align visibility and application timeouts |
| 4. Inventory workers | Supervisor, Horizon, systemd and container process lists | remove accidental duplicate managers |
| 5. Inspect deployment restarts | release logs and worker code version | use a graceful worker restart |
| 6. Locate late exceptions | external response, database commit and exception order | make the operation safe to retry |
| 7. Define a business key | order, invoice, tenant and operation identifiers | enforce idempotency at the right boundary |
| 8. Evaluate queue locks | cache driver, lock key, expiry and job class | use unique/overlap controls deliberately |
| 9. Reproduce safely | correlation logs from a staging test | verify the fix before replaying production jobs |
1. Was the job dispatched twice?
Add a correlation ID and a stable business-operation key when the producer dispatches the job. Log the event at dispatch and again at the beginning of handle(). Two distinct payload IDs point toward duplicate producer activity; one business operation appearing again after a delay points toward retry or redelivery. Check event listeners registered twice, overlapping scheduler entries, repeated webhooks, client retries and controller logic before touching worker settings.
2. Is --timeout safely below retry_after?
According to Laravel’s official queue documentation, the worker timeout should be several seconds shorter than retry_after. If the worker can continue after the queue makes the job available again, two workers may process it. Measure the real slow path—including HTTP calls—not only the average. Laravel also notes that blocking I/O should have its own connection and request timeouts. Check Laravel’s worker-timeout guidance.
3. Does SQS visibility match the real runtime?
According to AWS documentation, SQS uses a visibility timeout to control when an unacknowledged message becomes available again; Laravel therefore does not use its retry_after option for SQS. If processing and deletion do not finish before visibility expires, the message becomes available to another consumer. AWS also states that visibility timeout is not an exactly-once guarantee. Inspect the queue setting, worker runtime distribution and any visibility extensions together. Review AWS visibility-timeout behaviour.
4. Are two process managers starting the same workers?
After migration or deployment, Horizon may be running while an old Supervisor or systemd unit still launches queue:work. Multiple workers are valid when designed for concurrency; duplicate unmanaged configurations are not. List processes, containers and supervisor programs and map each one to a queue and deployment owner.
5. Did the deployment restart long-lived workers correctly?
Queue workers are long-lived and do not automatically notice new code. Laravel’s deployment documentation recommends php artisan queue:restart for a graceful exit after the current job, with a process manager bringing workers back. Verify the cache driver used for the restart signal and make sure old and new releases are not both consuming unexpectedly. See Laravel’s deployment guidance.
6. Did a side effect succeed before the job threw an exception?
A third-party API may accept a request, then the job may fail before persisting the success locally. A retry cannot know that the first attempt succeeded unless the integration uses an idempotency key, an operation record or a provider lookup. Do not treat “no local success row” as proof that nothing happened outside your system.
7. Is the operation idempotent?
Use a stable key derived from the business operation—not a random key generated on each attempt. Enforce it where correctness lives: a database uniqueness constraint, an operation ledger and/or a provider-supported idempotency key. For payments, shipments and irreversible actions, a short-lived cache lock alone is not a sufficient correctness boundary.
8. Should the job use ShouldBeUnique or WithoutOverlapping?
ShouldBeUnique prevents another matching job from being dispatched while the unique lock exists. WithoutOverlapping prevents matching work from executing concurrently and can release the overlapping job for another attempt. Both depend on a lock-capable cache and require carefully chosen keys and expiry. They complement idempotent business logic; they do not create a universal exactly-once guarantee. Compare Laravel unique jobs and overlap middleware.
9. Can you prove the fix with one controlled failure?
In staging, run one job with a known business key. Record dispatch count, attempt number, worker identity, start/end time and external request key. Then test a worker termination before acknowledgement and an exception after a simulated side effect. The expected outcome is not necessarily one execution; it is one correct business result.
How do duplicate dispatch and queue redelivery differ?
A producer-side duplicate begins before the queue has done anything wrong. A redelivery begins after reservation when processing, deletion or acknowledgement does not complete in time. Overlapping workers make the second case easier to observe, but concurrency itself is not proof of faulty configuration.
What evidence should the developer collect before changing configuration?
| Field | Example format | Why it matters |
|---|---|---|
| Correlation ID | quote-4821-email |
joins producer, worker and provider logs |
| Queue payload/job ID | driver-generated identifier | separates two dispatches from one redelivery |
| Attempt and worker | attempt=2 worker=queue-03 |
shows retry timing and concurrency |
| Business result key | unique operation row | prevents two committed outcomes |
| External request key | provider idempotency key | supports safe integration retries |
When is this a configuration repair, code repair or queue redesign?
- Configuration repair: timeout/retry values are unsafe, an old worker manager remains active, or deployment does not restart workers.
- Code repair: the producer fires twice, side effects are not idempotent, locks use the wrong key, or exceptions happen after external success.
- Integration repair: webhook retries, API timeouts and provider acknowledgements are not reconciled.
- Queue redesign: jobs combine too many side effects, runtimes are unbounded, ordering matters, or recovery requires manual database edits.
Do not blindly raise tries, clear failed jobs, make the visibility timeout extremely long or suppress exceptions. Those actions can hide evidence, delay recovery or repeat the costly side effect.
How can Dork Industry help repair a Laravel queue that runs twice?
Dork Industry can audit the dispatch path, queue and worker configuration, deployment process, logs, database boundaries and supported third-party integrations; reproduce the problem in a controlled environment; implement idempotency and overlap controls; and add operational monitoring. The engagement may be a focused PHP/Laravel repair, an integration fix or a broader application-backend improvement.
Review Dork Industry’s application development scope and industry solutions. Related failure patterns include a WordPress site breaking after a PHP update and a Shopify integration creating duplicate orders.
Request a Laravel queue assessment: share the queue driver, framework version, worker/Horizon configuration, deployment method, relevant timestamps, redacted logs and the business side effect that repeats. Dork Industry can scope a diagnosis, repair or developer-support engagement without promising an outcome before the evidence is reviewed.
Frequently asked questions
Why does my Laravel queue job run twice only after deployment?
Old workers may still run old code, a second process manager may start another worker pool, or changed timeout settings may not be loaded. Verify processes and use Laravel’s graceful worker restart procedure.
Will ShouldBeUnique stop every duplicate side effect?
No. It prevents matching jobs from being dispatched while its lock exists, subject to its cache and key configuration. Redelivery, lock expiry and side effects outside the queue still require idempotent business handling.
Can multiple Laravel workers safely process one queue?
Yes. Multiple workers are normal for concurrency. Jobs must be designed so retries and concurrent work do not create an incorrect business result, and operations that must not overlap need an appropriate lock or database rule.
What is the fastest safe first check?
Log one stable business key at dispatch and at job start. Then compare the worker timeout with retry_after or SQS visibility timeout. This quickly separates producer duplication from queue redelivery.