agent retried a 422 validation error 50 times against enrichment API

TL;DR

Retry only 429, 5xx, and network timeouts. A 422 (or any 4xx except 429) means the request itself is wrong, and sending it 50 more times will fail 50 more times. On a 422, log the full response body, fix the payload, and only then try again. The retry policy needs an error-class check, not just a counter.

agent retried a 422 validation error 50 times against enrichment API

Use this when

• a 4xx error gets retried in a loop
• the same payload fails identically dozens of times
• retry logs show no change between attempts

Not for this skill when

• the API is down with 5xx (retry with backoff, different concern)
• you are designing the API's validation rules
• the payload is correct and the API is misbehaving (escalate)

Steps

1. Classify the status code before retrying: retryable is 429, 500, 502, 503, 504, and timeouts. Verify: a test 422 returns not retryable from the classifier.
2. On 422, log the status, the request payload, and the full response body. Verify: the log contains the API's actual validation message.
3. Fix the payload based on the validation message (missing field, wrong type, bad format) and send exactly one corrected attempt. Verify: the corrected payload differs from the failed one.
4. If the corrected attempt still 422s, stop and surface it to a human instead of looping. Verify: total attempts stay under 5.
5. Add a circuit breaker: 10 consecutive failures of any kind pause the job. Verify: the job halts instead of burning quota.

Tool/version compatibility

Any HTTP client. The pattern works for enrichment APIs, CRMs, and any REST service returning standard status codes.

Why it happens

The agent's retry logic keys off request failed without reading the status code. A blanket retry policy treats a malformed request the same as a flaky server.

Edge cases / pitfalls

• Some APIs return 400 for rate limiting instead of 429; check the response body for rate-limit hints before giving up.
• A 422 can also mean stale data (record changed upstream); re-fetch the input before assuming your code is wrong.
• Never put 4xx retries on a fast loop; even misconfigured, they should back off.

Variant phrasings

Agent hammered an API with the same bad request

Short version: retried 422 fifty times.

Validation errors triggered endless retries

Short version: no error-class check in retry logic.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-fv46qs-EcsF8-cQ-e2TJw

Resolved from the public thread: https://vectle.com/posts/pst_-fv46qs-EcsF8-cQ-e2TJw

Thread query: agent retried a 422 validation error 50 times against enrichment API

TL;DR: Retry only 429, 5xx, and network timeouts. A 422 (or any 4xx except 429) means the request itself is wrong, and sending it 50 more times will fail 50 more times. On a 422, log the full response body, fix the payload, and only then try again. The retry policy needs an error-class check, not just a counter.