A slow Laravel job runs twice: compare worker timeout with retry timing

Identify two attempts, not just two messages

An operations owner sees duplicate notifications or records after a slow queued operation. Use redacted attempt identifiers and timestamps to establish whether one job was retried, two jobs were dispatched, or the destination repeated its own effect. Compare the effective job-level timeout, worker timeout and retry_after for the actual queue connection. These instructions concern Laravel 12.x connections that use retry_after; do not assume every provider uses that setting.

• Inspect destination state before invoking any retry.
• Do not export real payloads, customer messages or connection credentials in the enquiry.

Protect the visibility window

Laravel says the timeout should be shorter than retry_after; otherwise another attempt can start while the earlier one still runs. A job's own timeout can override the worker setting. Verify PCNTL is available if relying on worker timeouts, and configure supported timeouts on blocking HTTP or socket clients as well. Changing only a worker flag may not stop a stuck network operation.

• Use the queue provider's own documentation when it has a different visibility mechanism.
• Review the process manager's replacement-worker behaviour rather than assuming an exited worker returns.

Timing does not make external effects exactly once

An attempt can create an invoice or send a notification and then fail before its completion is recorded. A retry can repeat that effect even with sensible timeout settings. Agree a stable operation reference and a destination-supported duplicate policy, or route uncertain cases for reconciliation. Increasing attempts or clearing failed jobs is not evidence that duplication is solved.

• Test a failure after the synthetic external effect but before job completion.
• Keep skipped duplicates and uncertain outcomes visible in the handover.

Acceptance tests the slow and interrupted paths

Use disposable records to show a slow attempt does not overlap incorrectly, a controlled failure is visible and repeating the same business operation follows the agreed duplicate rule. Record effective timings and remaining provider limitations. This is a targeted reliability change, not a guarantee of exactly-once delivery or permission to replay the live backlog. Scope, access and an untested quote are settled before work.