A booking request times out. Can the client assume it failed?

Say it in 30 seconds

Say it like this (20-30 seconds)

No. A timeout tells the client it did not receive a result, not whether Postgres committed. MiniTickets retries booking with the same idempotency key so either the original booking is returned or the transaction is attempted safely. It retries network errors and server errors at most twice, but not client errors. I would keep the UI honest about uncertainty and never create a new key automatically for an unchanged intent.

The deeper answer

There are several possible timelines: the request never reached the API, the transaction rolled back, or it committed and the response disappeared. The browser cannot distinguish them from a network error alone. Sending the same parameters with the same user-scoped key makes that distinction unnecessary for correctness.

The retry helper permits two retries, giving at most three attempts. A 4xx response is not automatically retried. A 5xx or missing HTTP status may be ambiguous, so the idempotency contract makes those retries safe. This is specific to booking; arbitrary mutations should not gain retries by default.

Backoff limits immediate load, but it cannot prove completion. After retries are exhausted, the product should let the customer reconcile their booking rather than state that nothing happened. My tickets is a useful recovery view, while a durable intent history would strengthen recovery across a browser restart.

Counter-questions

Why not retry with a new key?

A new key means a new booking intent to the server. If the first request committed, that retry could buy seats twice.

What if the server returns 409?

The helper stops. The user may have requested unavailable seats or reused a key with different parameters. Repeating automatically does not resolve that decision.

Would a longer timeout fix this?

It may reduce some ambiguous responses while keeping callers waiting longer. It cannot remove the interval between commit and receipt of the response, so idempotency remains necessary.

Where in MiniTickets

Read Idempotency, then inspect the api-app piece →.

apps/web/src/features/bookings/lib/booking-retry.ts → shouldRetryBooking