A duplicate request no longer waits forever

Send two requests with the same Idempotency-Key at the same time, and the second one waits for the first to finish. It then replays the first response. That has not changed.

What changed is the wait. It used to have no limit. It is now capped at 10 seconds.

What you will see

Almost always, nothing new. The first request finishes in well under a second, and the second one replays its response as it always did.

If the first request is still running after 10 seconds, the second one stops waiting. It returns 409 Conflict with a Retry-After: 1 header.

Read that as “try again shortly”, not as “this request was wrong”. Wait the number of seconds in the header, then send the same request again, with the same key and the same body.

Telling the two 409s apart

A 409 with a Retry-After header means the first request was still running. Retry it.

A 409 without that header is the older case: you used the same key with a different body. Retrying will not help, because the request itself is the problem.

If your code already treats every 409 as a permanent failure, this is the one place worth a second look.

Why it changed

The old behaviour could hold a database connection for as long as a request took. Under enough load, that starved the pool and requests piled up behind each other.

The engine no longer holds a connection while it waits. A slow request now fails on its own instead of blocking your other traffic. Each request also has its own ceiling of 25 seconds.

Nothing here changes what gets stored, what gets replayed, or how long a key lasts. Keys still expire after 24 hours, and 5xx responses are still never cached.