{
  "id": 6605313,
  "title": "A Series of Unfortunate Jobs",
  "url": "https://urgent.news/2026/09/10/a-series-of-unfortunate-jobs",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-10T15:47:32.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/oussamamater/a-series-of-unfortunate-jobs-33bk"
  },
  "original_language": "en",
  "account": "Laravel queues can be a source of confusion, but they are an essential part of any modern web application. Over time, mistakes are made, and valuable lessons are learned. Claude is currently pondering the consequences of these mishaps, eagerly awaiting to share them.\n\nIn the first instance, a job designed to send a reminder for an abandoned shopping cart was implemented. The code dispatched the job, with a delay of a day, along with a retry mechanism that would attempt the job for 10 minutes if the mail provider experienced issues. However, the reminder never made it out. This occurred because the retryUntil() function was evaluated when the job was pushed onto the queue, not when it was executed. By the time the job became available to the workers, the expiration timestamp had long passed. The worker then failed the job with a MaxAttemptsExceededException, and the handle() method never ran.\n\nThe second example involved a job that synced order information to a CRM system. The code demonstrated a lack of specified retries, which typically would result in a single attempt. However, when running Horizon, the default behavior changed. Horizon defaults to attempting a job zero times, meaning the job would be retried indefinitely if it failed. The supervisor name was also given a more descriptive name, supervisor-1, to avoid confusion. In a production environment, Horizon was used, which led to the job being retried indefinitely if it failed.\n\nThe third scenario focused on unique jobs. A job was created to sync order information to a CRM system, and it was marked as both ShouldQueue and ShouldBeUnique. This ensured that if the job was already running, subsequent attempts would not be processed. However, the lock would only be released once the job started processing. If the job was stuck in the queue for a long time due to high load, the lock would remain in place. If ShouldBeUniqueUntilProcessing was used instead, the lock would be released as soon as processing started, preventing subsequent attempts from being skipped.",
  "summary": "You can't tell me Laravel queues haven't bitten you at least once. It's great that we get them out of the box, but man, they can be confusing as hell sometimes. Over the years, I've screwed up, more than once, and collected quite a few lessons along the way. Claude is currently Pondering.. , I'm waiting, and bored, so shall we? Gotcha #1 I want you to look at the code below and tell me if you can…",
  "key_points": [
    "Reminder job failed due to retryUntil() evaluated at job dispatch, not execution.",
    "Horizon defaults to zero retries for jobs, causing indefinite retries in production.",
    "ShouldBeUnique ensures lock release upon processing start, not completion."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}