HTTP 500 is no longer retryable

Nobody has started this yet — be first.

Business impact

500 Internal Server Error is the single most common status code a struggling downstream returns. If this library's retry classifier no longer treats it as retryable, every charge (or any other operation wrapped in this executor) that hits a transient 500 short-circuits immediately instead of retrying -- landing in the DLQ after exactly one attempt, during exactly the kind of brief downstream blip retries exist to absorb. That's the difference between "the customer's payment succeeded on the automatic 3rd attempt, they never noticed" and "the customer's payment failed and support has to manually explain what a dead-letter queue is."

Problem

HTTPError.Retryable() is documented as "429 (rate limited) and any 5xx (server error) are [retryable]". The comparison it actually performs excludes exactly 500 from that set.

Current behavior

(&retry.HTTPError{StatusCode: 500}).Retryable() returns false.

Expected behavior

It should return true, exactly like 501, 502, 503, and every other 5xx already do.

Steps to reproduce

err := &retry.HTTPError{StatusCode: 500, Status: "500 Internal Server Error"} fmt.Println(err.Retryable()) // got: false, want: true

Why this matters

This one-character boundary bug silently narrows "any 5xx" to "any 5xx except the single most common one", which is the opposite of an edge case -- it's the common case being wrong while the edges (501, 503, ...) are right, making it easy to miss in ad-hoc testing that happens to poke a different status code.

Suggested approach

Retryable()'s doc comment says "any 5xx (server error)". Compare the comparison operator it actually uses against that documented contract -- the boundary value (500 itself) is the tell.

Acceptance criteria

HTTPError{StatusCode: 500}.Retryable() returns true.
HTTPError{StatusCode: 503}.Retryable() still returns true (sanity: this bug shouldn't regress 5xx values that already worked).
HTTPError{StatusCode: 400}.Retryable() still returns false.
go test ./test/ -run TestTask02 -v passes.

Verification

go test ./test/ -run TestTask02 -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/http-error-500-boundary

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/http-error-500-boundary

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.