Make handlers idempotent

• Always design handlers so they can be executed multiple times safely. Example: thumbnail generation should check if a thumbnail already exists and skip or overwrite safely; order outbox handlers should check whether an event was already published/processed.
• Idempotency is the single most important property to make retries safe.

Visibility and atomic handoff (for external queues)

• In external queues (SQS, Redis Streams, RabbitMQ), consumers claim a message and it becomes visible only when they ack. If the consumer dies without ack, the message becomes visible again (visibility timeout). You should mirror that semantics:
  • when you poll outbox DB, mark the row in_progress with a worker_id and a locked_until timestamp (or use SELECT ... FOR UPDATE SKIP LOCKED pattern).
  • commit that change so other workers don't pick it (claiming).
  • if claimed worker crashes, other workers can pick after locked_until expires.
• For in-memory queue you don’t need visibility semantics, but if you want failover across processes you must use persistent queue or outbox+DB claim.

so in external queues we don’t need to use locking here ? **

If handler raises and you swallow the error (catch + not requeue), the item is done: queue.task_done() is called and the message is lost (no retry).

If you want retries :

• In-memory re-enqueue: when handler fails, increment attempts, schedule asyncio.create_task(delayed_reenqueue(...)) which does await asyncio.sleep(backoff) then queue.put_nowait(item). Works while process is alive.
• Persistent retry via outbox: update outbox.attempts and available_at in DB; leave it to the outbox poller/publisher to pick it up later. This survives process crash.

Where to attach metadata:

• If you publish directly from the route, add metadata to the item (e.g. {"event":"image_uploaded","data":..., "attempts":0, "max_attempts":3, "outbox_id": None}).
• If you use an outbox, the outbox row will have id, attempts, available_at, status. When the outbox poller claims the row it can create an in-memory item that includes outbox_id.

when an outbox poller claims the row will it publish it to queue just like as we are publishing(enqueing) from route