queue-and-retry-safety

Enforce idempotency, DLQ policies, and visibility timeouts for queue-based processors.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/lgerard314/global-plugin --skill queue-and-retry-safety
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: queue-and-retry-safety
Source: https://github.com/lgerard314/global-plugin/tree/main/plugin/skills/queue-and-retry-safety
Command: npx skills add https://github.com/lgerard314/global-plugin --skill queue-and-retry-safety

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Queues are at-least-once by design, which means duplicates and replays can lead to data corruption or duplicated work unless proper guardrails are enforced. This skill provides a systematic approach to enforce idempotency, DLQ governance, visibility timeout strategies, and correlation tracking for reliable queue processing.

Core Features & Use Cases

  • Idempotency and guarded side effects: ensure repeated deliveries do not cause duplicate work or state changes.
  • DLQ topology and alarms: consistent dead-letter handling with monitoring to catch poison messages early.
  • Visibility timeout management: heartbeat long-running jobs and set appropriate base timeouts to minimize re-delivery.
  • Payload validation and correlation propagation: verify payload shape and propagate correlation IDs through logs and downstream calls.

Quick Start

Configure idempotency checks, DLQ alarms, and visibility timeouts for your queue-based workers to ensure safe retries across SQS, EventBridge, and similar event-driven systems.

Frequently Asked Questions about queue-and-retry-safety

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent duplicate processing when queue retries deliver the same message twice?

Queue retries cause duplicate processing unless you enforce idempotency checks using unique keys. Guarding side effects ensures repeated deliveries do not trigger duplicate state changes or duplicated work across SQS, EventBridge, or BullMQ workers.

What's the best way to handle poison messages in SQS or EventBridge before they block the queue?

Poison messages are handled by enforcing consistent dead-letter queue (DLQ) topology with alarms. This approach catches undeliverable messages early, retaining error context for inspection and preventing continuous blocking of queue-based workers during redrive scenarios.

How do I set visibility timeouts for long-running Lambda event sources to avoid premature re-delivery?

Visibility timeouts prevent premature re-delivery by hiding in-flight messages until processing completes. For long-running jobs, heartbeat extensions and appropriate base timeouts minimize duplicate deliveries across distributed systems like SQS and BullMQ workers.

Does this approach to queue safety work with both producers and consumers in async job processors?

Yes, queue safety covers both publishing and consuming paths in async job processors. It propagates correlation IDs through logs and downstream calls, applies payload validation, and works across SQS, EventBridge, and BullMQ distributed systems.

Why do I need a correlation ID when retrying failed messages in distributed systems?

Correlation IDs track message lifecycle across producers, consumers, and logs during retries. Propagating them ensures traceability of failed deliveries and error context retention, which is critical for debugging redrive scenarios in distributed queue-based systems.