[eskit] DLQ Replay should be idempotent or use optimistic locking #33

New issue

Open

opened 2026-02-28 03:07:16 +00:00 by ash · 0 comments

ash commented

2026-02-28 03:07:16 +00:00

Owner

Architectural Concern

The DLQ Replay fix (take exclusive lock, delete before replay, put back on failure) works but has a subtle issue: if replayFn fails, the entry is put back — but its position in the order slice may have changed if other entries were added/deleted during the replay.

For production DLQ implementations (SQLite/Postgres), consider:

A replaying status flag + timestamp to prevent concurrent replay
Optimistic locking via a version field
Or just document that Replay must be called from a single goroutine

Found during red team audit 2026-02-28.

## Architectural Concern The DLQ Replay fix (take exclusive lock, delete before replay, put back on failure) works but has a subtle issue: if `replayFn` fails, the entry is put back — but its position in the `order` slice may have changed if other entries were added/deleted during the replay. For production DLQ implementations (SQLite/Postgres), consider: 1. A `replaying` status flag + timestamp to prevent concurrent replay 2. Optimistic locking via a version field 3. Or just document that Replay must be called from a single goroutine Found during red team audit 2026-02-28.