transaction resolution unknown
Production Risk
Critical: silent duplicate writes if the original commit succeeded and a retry is issued without verifying state first.
SQLSTATE 08007 is raised when the connection breaks at exactly the point where Postgres was committing a transaction, leaving it unknown whether the commit succeeded or failed. This is the most dangerous connection error because the application cannot know the outcome without querying the database.
- 1Network failure or server crash precisely during the COMMIT flush to WAL
- 2Connection pool killing a connection at the moment of commit
Connection fails mid-COMMIT during a payment or order write.
expected output
ERROR: connection failure during transaction commit — transaction resolution unknown
Fix 1
Query the database to determine whether the transaction committed
WHEN Immediately after catching 08007.
-- Check for presence of a known side-effect of the transaction: SELECT COUNT(*) FROM orders WHERE order_id = :order_id;
Why this works
Reconnect on a fresh connection and check for business-observable evidence of the transaction. If present, the commit succeeded; do not retry. If absent, the commit failed; retry is safe.
Fix 2
Use idempotent operations with a client-generated idempotency key
WHEN When designing systems that must tolerate uncertain commits.
INSERT INTO orders (order_id, ...) VALUES (:client_uuid, ...) ON CONFLICT (order_id) DO NOTHING;
Why this works
A client-supplied UUID as the primary key makes the insert idempotent. Retrying after 08007 is safe because a duplicate insert is silently ignored.
✕ Retry the transaction blindly after 08007
If the original transaction committed, a blind retry causes duplicate data (double charges, duplicate orders, etc.).
Class 08 — Connection Exception
Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev