DLQ job's first/last failure timestamps are swapped

Nobody has started this yet — be first.

Business impact

FirstFailedAt/LastFailedAt are exactly the two fields an on-call engineer glances at first when triaging a dead-lettered job -- "how long has this been broken?" With the fields swapped, that duration (LastFailedAt - FirstFailedAt) comes out negative, which is either confusing (if a human reads it) or silently wrong (if a dashboard/alert computes "age of oldest failure" from it and gets nonsense). Neither is catastrophic on its own, but it's exactly the kind of subtly-wrong observability data that erodes trust in a monitoring dashboard over time.

Problem

dlq.NewJob is supposed to record the timestamp of the earliest attempt as FirstFailedAt and the latest as LastFailedAt. It assigns them backwards.

Current behavior

Given a retry.Result whose attempts are in chronological order (as retry.DoWithResult always produces them), the resulting Job's FirstFailedAt is actually the timestamp of the last attempt, and LastFailedAt is the timestamp of the first attempt.

Expected behavior

Job.FirstFailedAt should equal the earliest attempt's timestamp; Job.LastFailedAt should equal the latest attempt's timestamp.

Steps to reproduce

result := retry.Result{Attempts: []retry.Attempt{ {Number: 1, Timestamp: t0}, {Number: 2, Timestamp: t0.Add(3 * time.Second)}, }} job := dlq.NewJob("id", "op", nil, result) fmt.Println(job.FirstFailedAt.Equal(t0)) // got: false, want: true

Why this matters

FirstFailedAt/LastFailedAt are part of the public Job struct exposed via GET /v1/dlq and GET /v1/dlq/{id} -- any dashboard or alerting rule built on top of this API inherits the swap.

Suggested approach

Look at NewJob in pkg/dlq/job.go: it derives first/last from result.Attempts[0] and result.Attempts[len(result.Attempts)-1]. One of those two indices is assigned to the wrong variable.

Acceptance criteria

For a multi-attempt retry.Result, Job.FirstFailedAt equals the earliest attempt's timestamp and Job.LastFailedAt equals the latest's.
go test ./test/ -run TestTask05 -v passes.

Verification

go test ./test/ -run TestTask05 -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-job-timestamp-swap

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-job-timestamp-swap

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.