Timeouts, retries and idempotency keys

No response does not prove no operation.

UnderstandStudy an examplePractise

Understand the concept

A client timeout may occur after the server committed an operation. Connection, TLS, response and total-deadline limits have different scopes. Retries must stay inside the total budget. Cancellation propagation is useful but does not guarantee rollback.

An idempotency key is an application contract, not universally automatic behaviour. Define scope, payload fingerprint, expiry, concurrent handling and result retention. Reusing a key for a different payload should be treated as a conflict.

Retrieving operations is generally easier to retry, but retries do not fix persistent 400/403 errors. Queryable operation identifiers can resolve uncertain outcomes.

WHEN TO USE IT

Prevent duplicated payments, applications or messages.

COMMON PITFALL

Retrying an uncertain POST with a new operation identity.

01 / PRACTICE

One topic. Three levels of depth.

HTTP / illustrative example

Client timeout → outcome unknown

Reconcile the server outcome separately.

This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.

02 / YOUR TURN

Try it yourself first.

Does timeout mean the operation failed?

Show the solution and explanation

Worked solution

Timeout = unknown outcome until reconciled

Not necessarily; the outcome can be unknown.

RasimAtaberkŞahin

Understand the concept

One topic. Three levels of depth.

Try it yourself first.