Idempotency

Two distinct deduplication concerns, two different owners:

• Publish dedup — SimpleQ handles this. Set idempotencyKey on publish; a double-publish with the same key returns the existing job rather than creating a duplicate.
• Redelivery dedup — your worker handles this. In ack mode, a worker that succeeds (spends tokens, writes results) but dies before sending /ack will be redelivered after the ack timeout. If your work has cost (LLM tokens, downstream API quota, third-party writes), your worker must dedupe by job ID so the second delivery doesn't re-pay it.

Stub

This page is a stub. Recipes are linking to it. Real content lands soon.

TODO — content

• The idempotencyKey field on publish, what it covers, and what it doesn't.
• The redelivery scenario in ack mode: silent success → ack timeout → second delivery.
• A minimal dedup pattern: in-memory Set for development; a Redis or DB key with a TTL longer than the ack timeout for production.
• Why this is the worker's job: SimpleQ guarantees delivery, not execution.