'db:connection-closed' error when retrying writes in Racket's db library

Question

The Racket db library throws a 'db:connection-closed' exception when a connection is lost during a transaction. The documentation does not specify how retrying such a write should be handled, leaving the developer to decide whether to re‑execute the statement. Re‑execution can result in duplicate rows because the library provides no built‑in duplicate‑write detection or idempotency tracking. Meanwhile, the http client offers a retry keyword for GET requests but not for POST or other state‑changing methods, creating a similar asymmetry for HTTP writes.
Given this gap, should Racket introduce a higher‑level abstraction that safely retries write operations without risking duplication? 1) How might such an abstraction detect whether a write has already been applied after a failure? 2) Could unique constraints or operation IDs be leveraged to enforce idempotency? 3) What trade‑offs would arise from adding automatic retry logic to the db and http libraries?

Tasadduq Burney · Answer

Answering the Core QuestionWhen a Racket db transaction loses its connection, the library throws a 'db:connection-closed' exception and rolls back the transaction automatically. The library does not provide a built-in retry path, so the developer must decide whether to re-execute the statement. Re-executing can produce duplicate rows unless the write is protected by a unique constraint or an idempotency token.

Confirmed Facts
The db library rolls back automatically on 'db:connection-closed.
Re-executing the same INSERT without a unique constraint creates a duplicate row.
Adding a unique constraint or an operation-ID column causes the second attempt to raise a unique-key violation instead.
HTTP client retry support currently exists only for GET; POST and other state-changing methods lack built-in idempotency handling.

Suggested Retry Abstraction for Writes
Wrap the write in a transaction. Begin a transaction, perform the write, and commit.
Catch the 'db:connection-closed' exception. When caught, close the old connection, create a new one, and retry the transaction.
Detect duplicates via unique constraints. Ensure the target table has a unique key on a business-critical column or an explicit operation_id column.
Use an idempotency token. Generate a UUID per logical operation, store it in operation_id, and check for its existence before performing the write.
Return a clear result. If the retry fails again, surface the original 'db:connection-closed with context; otherwise, return the successful result.

Detecting Whether a Write Has Already OccurredThe most reliable method is to rely on the database’s unique constraint engine. When the retry is attempted, the second attempt will raise a constraint instead of inserting a duplicate.

Unique Constraints or Operation IDsGenerate a UUID per logical operation, store it in operation_id, and check for its existence before performing the write. This enforces idempotency at the data layer level.

Trade-offs of Automatic Retry Logic
Pros: Simplifies code, reduces boilerplate, and ensures consistent retry semantics.
Cons: Adds runtime overhead, may mask transient issues, and increases cognitive load for developers who expect explicit control over transaction boundaries.

Diagnostic: Does the target table already enforce a unique constraint on the column you are inserting?

'db:connection-closed' error when retrying writes in Racket's db library

1 answer

Answering the Core Question

Confirmed Facts

Suggested Retry Abstraction for Writes

Detecting Whether a Write Has Already Occurred

Unique Constraints or Operation IDs

Trade-offs of Automatic Retry Logic

Your perspective belongs here.

1 question comment

What the exception really means

How to safely retry

Why a blanket retry is risky