Redis-backed DLQ lists jobs newest-first, not oldest-first

Nobody has started this yet — be first.

Business impact

GET /v1/dlq is the list an on-call engineer works through during an incident, and the documented (and generally correct) triage order is oldest-first -- the job that's been failing the longest is usually the most SLA-critical, and working newest-first means it gets addressed last, if at all, once the queue empties enough that someone stops looking. This bug only affects the Redis backend, which is specifically the one this project recommends for production (STORE_BACKEND=memory is the zero-setup dev default) -- so it's the textbook "worked fine in every local/dev test, broke specifically in the production configuration" pattern.

Problem

dlq.Store.List is documented (and MemoryStore's implementation still does this correctly) to return jobs oldest-first. RedisStore.List's sort comparator is inverted.

Current behavior

RedisStore.List(ctx) returns dead-lettered jobs newest-first. MemoryStore.List(ctx) is unaffected and still returns oldest-first.

Expected behavior

Both backends return jobs in the same order: oldest CreatedAt first.

Steps to reproduce

store := dlq.NewRedisStore(client) store.Push(ctx, dlq.Job{ID: "a", CreatedAt: t0}) store.Push(ctx, dlq.Job{ID: "b", CreatedAt: t0.Add(time.Second)}) list, _ := store.List(ctx) fmt.Println(list[0].ID) // got: "b" (newest), want: "a" (oldest)

Why this matters

Both backends are supposed to be interchangeable behind the same Store interface -- a caller (or test) that only exercises the memory backend in CI and only discovers the Redis backend's behavior in staging/production learns about this divergence at exactly the wrong time.

Suggested approach

Compare RedisStore.List's sort.Slice comparator in pkg/dlq/redis.go against MemoryStore.List's in pkg/dlq/memory.go -- they should be doing the identical comparison; only one of the two currently is.

Acceptance criteria

RedisStore.List returns jobs oldest-CreatedAt-first.
go test ./test/ -run TestTask09 -v passes.
The pre-existing TestStore_ListOrdersByCreationTime/redis in pkg/dlq/store_test.go also passes again.

Verification

go test ./test/ -run TestTask09 -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/dlq-redis-sort-direction

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/dlq-redis-sort-direction

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Reliability Layer (Idempotency + Retry + DLQ)

Idempotency, retry-with-jitter, and a dead-letter queue, as three standalone Go libraries plus a runnable HTTP demo -- fifteen ways the payments-style plumbing most real systems get subtly wrong quietly breaks.

Fork on GitHub

Download

Setup

Reliability Layer (Idempotency + Retry + DLQ)

git clone <your-fork>
cd GolangDevTraining/reliable
go run ./cmd/server   # memory backend by default -- no Redis or Docker needed
# in another shell:
curl localhost:8080/healthz

The service runs on . Walk through the README's five core scenarios against (plain success, idempotent replay, conflicting-payload rejection, concurrent duplicates collapsing to one execution, and exhausted retries landing in the DLQ) to see the whole system working end to end.