---
title: "2026-08-10 · A duplicate request no longer waits forever"
description: "When two requests share an Idempotency-Key, the second one waits at most 10 seconds. Past that it returns 409 with a Retry-After header instead of hanging."
order: 0
date: "2026-08-10"
---

# 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.