padosoft-durable-effectslisted

Use this skill when work leaves the request and happens later — a background job, a queue, a worker, a webhook consumer, a scheduled task, a retry — and whenever the user reports that something ran twice, that a job was processed by two workers, that a retry charged or sent a second time, that a cancelled job still reported success, that a worker hung or exited with a late error, or that a job vanished. It covers lease and fencing semantics, exactly-once effects, terminal states, cancellation, and what a durable queue needs that an in-memory one does not. Do not use it to choose a queue technology, to tune throughput or worker counts, or for request-scoped transactions (padosoft-atomic-invariants covers those).
padosoft/skills · ★ 1 · AI & Automation · score 80

Install: claude install-skill padosoft/skills

# Durable effects A queue moves *work*. It does not move **effects**. Everything below is a way a system with a correct queue still charges twice, ships twice, or reports success for something it killed. **The rule: claim the effect atomically before performing it, and make every terminal outcome a state you can read back.** --- ## 1. Delivery is not the problem. The effect is ```text signature verified → still not idempotent lease reclaimed → still not exactly-once retry with the same key → still a second charge, unless something refused it ``` A valid retry carries a valid signature and runs capture, fulfilment or entitlement again. Verification and idempotency are **two separate prior checks**, and only one of them protects the effect. **Claim a logical effect key atomically before running the effect**: treat the same event as a duplicate, and reject a *different* event that reuses the key. In a multi-replica deployment the unique constraint in the durable store is the boundary — not a check in application code, and not a cache. ## 2. Reclaiming a lease is a race you can lose quietly A stale processing claim has to be reclaimable after a crash, or a dead worker blocks the queue forever. But the previous holder may have completed the external side effect **in the moment before it died**. The ledger can stop the duplicate *state transition*. Only an idempotency key on the external side makes the external operation safe across that reclaim. If the downstream