## TL;DR

Make retries fire only on retryable statuses (429 and 5xx), never on 400. A 400 means the request is malformed; replaying the identical bad request five times looks like abuse. Fix the malformed request, then gate retries by status code.

```
generated client's retry logic retried 400s  -  a malformed request was replayed 5 times and triggered the provider's fraud flags
```

## Steps

1. Pull one failed request and read the 400 response body. Providers usually name the offending field. Expected: you know exactly what was malformed.

2. Fix the request construction so the malformed field is correct or omitted. Expected: a single manual request now returns 2xx or a different, legitimate error.

3. Change the retry policy: retry only on 429 and 5xx (and network errors); treat 400, 401, 403, 404, 422 as final. Expected: the retry config lists explicit retryable statuses instead of "retry on any error".

4. Add idempotency keys to mutating requests so that even a legitimate retry can never double-apply. Expected: replays are safe by construction.

5. Check the provider dashboard or contact support to clear the fraud flag if the account is still restricted. Expected: the flag is lifted and stays lifted.

6. Add an alert on repeated identical 400s so a malformed request gets fixed on the first occurrence instead of the fiftieth. Expected: the next malformed request pages someone after a small threshold, not after a ban.

## Use this when

- Logs show the same request failing with 400 multiple times in a row.
- An account got flagged or throttled after a burst of identical bad requests.
- A generated retry wrapper retries on "any error" without status gating.

## Not for this skill when

- Retries are hitting 429 or 5xx - that is legitimate retry behavior, tune backoff instead.
- The 400 comes from the provider side changing validation - then the request was fine yesterday; update it to the new rules.
- The problem is duplicate side effects from successful retries - that is idempotency, not retry gating.

## Variant phrasings

- retry logic replayed 400 bad requests and triggered fraud detection
- generated client retries malformed requests until account flagged
- provider fraud flags from repeated identical 400s

## Why it happens

Generated retry wrappers usually catch broadly: "if the request failed, try again." A 400 fails, so it retries, and the request is deterministic, so the same malformed body goes out five times. Fraud systems are tuned to flag exactly that shape: identical failing requests at machine speed.

## Edge cases

- 400s caused by transient provider-side validation deploys are rare; still treat 400 as final and alert a human.
- Some providers return 400 for rate limiting (undocumented); if you see this, gate on the response body, not just the status.
- Retry budgets: cap total attempts even for retryable statuses so a poison request cannot loop forever.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bx7UQUjz8p2vA562NkAItA