Tech-Reader.blog

  Happy New Year! 🎉 # python # 2026 # coding # strongcoffee Clean code, fewer bugs, and elegant solutions in 2026. Happy New Year, everyone. 🎉

  The Secret Life of JavaScript: Inheritance # javascript # coding # programming # softwaredevelopment Timothy stood in the center of the archive room, holding a slim, leather-bound ledger labeled  childObject . He flipped through its pages frantically, his brow furrowed in frustration. "It’s not here, Margaret!" he cried out. "I called for the  speak()  method on this object, but the pages are blank. The function is missing. The code should crash!" Margaret, calm as ever, walked over from the main desk. She didn't look at the ledger in Timothy's hand. Instead, she pointed to a small, faded stamp on the inside of the back cover. "The function is not missing, Timothy," she said softly. "It is simply not  local . In this library, we do not copy every single instruction into every single book. That would be wasteful. Instead, we rely on  Lineage ." The "Link" (The Prototype) Margaret took the  childObject  ledger from his hands and...

  AWS SQS Error: 'QueueDeletedRecently' vs. Eventual Consistency # aws # sqs # lambda # cloud QueueDeletedRecently  is often misdiagnosed as eventual consistency, but the two are very different. Problem You delete an Amazon SQS queue and then immediately try to recreate it—often via Terraform, CloudFormation, CDK, or a CI/CD pipeline—and the operation fails with an error similar to: QueueDeletedRecently: You must wait 60 seconds after deleting a queue before you can create another with the same name. Retries don’t help. Re-running the pipeline doesn’t help. Nothing appears wrong with your configuration. Clarifying the Issue This error is  not  caused by eventual consistency. It is caused by a  deliberate deletion protection window  enforced by Amazon SQS. When you delete a queue, SQS reserves that queue name for a short period (approximately 60 seconds). During that window: The queue is fully deleted The name is intentionally blocked Recreation with the sam...

  AWS SQS Error: FIFO '.fifo' Naming and Deduplication Traps (Messages Rejected, Ignored, or Duplicated) # aws # sqs # lambda # cloud If you respect the  .fifo  suffix, set  MessageGroupId  correctly, and understand deduplication behavior, FIFO works exactly as advertised. Problem You create an Amazon SQS FIFO queue and immediately run into one or more of the following: Messages fail to send with vague or confusing errors Messages are silently  deduplicated  when you expect them to be processed Messages are processed  out of order  despite using FIFO Your producer “works” with a standard queue but fails with FIFO Nothing in your code  looks  wrong, yet FIFO behaves nothing like you expected. Clarifying the Issue FIFO queues are  strict by design . They enforce rules that standard queues do not. Most FIFO failures are not bugs—they are  contract violations . In practice, problems almost always come down to  three requi...

  AWS SQS Error: Visibility Timeout vs. Lambda Timeout Misalignment (Duplicate Processing & Phantom Retries) # aws # sqs # lambda # cloud Once the timeouts are aligned—and partial batch responses and idempotency are in place—the system becomes predictable, stable, and boring again. Problem Your Amazon SQS–triggered Lambda function appears to “work,” but you start seeing: Messages processed  more than once Duplicate records written to databases Side effects repeated (emails sent twice, files processed twice) Dead-letter queues filling unexpectedly No errors are logged. Nothing looks obviously broken. Yet the system behaves unpredictably. Clarifying the Issue This is almost never a bug in Lambda or Amazon SQS. It is a  timeout mismatch . Specifically: ❌ Your Lambda timeout is longer than the SQS visibility timeout . When this happens, SQS assumes the message was not processed successfully and makes it visible again— while your Lambda is still running . The result: the s...