In-memory janitor evicts active idempotency keys almost immediately

Nobody has started this yet — be first.

Business impact

The entire point of an idempotency key is that it survives long enough for a retried request to find it. If the background janitor deletes keys before they expire instead of after, the at-most-once guarantee this whole project exists to provide breaks down for any request slower than one sweep interval (one minute by default): a retry that lands after the key was wrongly evicted sees Proceed instead of Replay/InProgress and re-executes the operation -- silently reintroducing the exact duplicate-charge risk this library is supposed to eliminate. The other half of the same bug (expired keys are never evicted at all) is a slow, unbounded memory leak in the opposite direction.

Problem

MemoryStore's background janitor is supposed to delete entries whose TTL has passed (now is after expiresAt). The comparison it actually uses is backwards.

Current behavior

A key created with a 5-second TTL is gone from the store within roughly one sweep interval (as little as ~20ms in a fast-sweep configuration, up to the default 1-minute interval otherwise) -- long before its TTL actually elapses. Meanwhile, a key that has genuinely expired is never swept.

Expected behavior

Only entries whose expiresAt is in the past should ever be deleted by the janitor; a key with time remaining on its TTL must survive sweeps indefinitely until it either completes its lifecycle normally or its TTL genuinely elapses.

Steps to reproduce

store := idempotency.NewMemoryStoreWithSweepInterval(5time.Second, 20time.Millisecond) defer store.Close() store.Begin(ctx, "fresh-key", "fp", 5*time.Second) time.Sleep(150 * time.Millisecond) // several sweeps, nowhere near the 5s TTL _, ok, _ := store.Get(ctx, "fresh-key") fmt.Println(ok) // got: false, want: true

Why this matters

This is the worst kind of correctness bug: it's invisible in a quick manual test (a curl sent right after the fix would "work"), but corrupts the guarantee under exactly the condition -- any request slower than the janitor's sweep interval -- that idempotency keys with a multi-hour TTL were provisioned to handle in the first place.

Suggested approach

sweep() in pkg/idempotency/janitor.go compares now against each entry's expiresAt with a single boolean condition. Think about which direction "has this entry's time run out" should point, and compare that to what the condition currently does -- the fix is a single method call swap (.After vs. .Before), not a restructuring.

Acceptance criteria

A key with time remaining on its TTL survives many janitor sweep cycles.
A key whose TTL has genuinely elapsed is eventually swept (not required by the dedicated test, but worth confirming manually).
go test ./test/ -run TestTask07 -v passes.
The pre-existing TestMemoryStore_JanitorEvictsExpiredKeys in pkg/idempotency/memory_test.go also passes again.

Verification

go test ./test/ -run TestTask07 -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/idempotency-janitor-cutoff-sign

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/idempotency-janitor-cutoff-sign

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.