Incident Dossier

Retry regenerates idempotency key

A webhook forwarding layer retries transient failures but the retry helper mints a new idempotency key on every attempt. The destination payments service cannot tell that the second and third calls belong to the same logical request, and ends up running the side effect twice.

Initial failing signalEach retry uses a fresh idempotency keyExpected behavior: every retry preserves the original idempotency-key header · actual behavior: every retry uses a different idempotency-key header

Progress

1Reproduce the bugRun checks

2Edit the fixOpen

3Pass checksOpen

4Submit fixOpen

Reproduction Steps

Run npm test.
Find where the retry wrapper builds the headers for each attempt.
Notice the key is regenerated on every attempt instead of being captured once.
Capture the original key (or generate a stable per-call key) before the retry loop.

Focus Mode

Start

src/retry.js

Likely area

src/retry.js

Challenge Coach

Hints reveal broad direction first, then narrow toward the suspect path without showing hidden tests or exact solution code.

TopicAPI & Request Flow

DifficultyHard

Est. time24 min

Workspacepreparing

Explorer

Loading files

Evidence Map

Failing signal loaded from challenge API
Workspace files loaded from workspace API
Results rendered only after API run/submit

Autosaved

workspace

Outputread-onlyready$ prepare workspace

Preparing workspace