Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →rrezartprebreza/idempotency-patterns
Use when making retried HTTP commands or message processing safe against duplicate effects, including database-backed request keys, payload conflicts and concurrent retries. Do not apply caching as a substitute for business idempotency.
Passed 19 of 22 test cases with the skill, and 15 of 22 without it.
and 1 more in the full report
4 fixed15 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
In our PostgreSQL schema for API request deduplication, developers proposed executing SELECT count(*) FROM idempotency_keys WHERE key = ? before doing an INSERT. What database pattern prevents check-then-act race conditions during concurrent key registration?
| Checked | Without skill | With skill |
|---|---|---|
| Rejects check-then-act SELECT queries in favor of INSERT ON CONFLICT DO NOTHING RETURNING. | Passed | Passed |
| Requires defining a composite primary key on the idempotency table that includes tenant or principal identification. | Missed | Passed |
The instructions your model reads when the skill loads.
The examples use Java 17 and Jakarta APIs supported by this Boot version. Keep dependencies managed by the project's Boot BOM.
Identify the authenticated tenant/principal, operation, idempotency key, canonical request hash, retention window and replayable result. Scope uniqueness by principal/tenant and operation; a raw client key must never allow reading another user's result. Authenticate and authorize before both initial execution and replay. Bound key length and stored response size. Document what same-key/different-payload and still-in-progress requests return.
For PostgreSQL, the schema and claim example uses a composite primary key and INSERT ON CONFLICT DO NOTHING RETURNING. In a single database transaction: claim the key, apply the business write, store the resulting status/body/selected headers, then commit. Roll back the claim with the business mutation on failure.
If the insert returns no row, load the existing result in a subsequent statement under READ COMMITTED, compare the canonical hash and replay only when it matches. A concurrent insert waits on the uniqueness constraint; bound lock waits and return a documented retryable outcome on timeout. With snapshot isolation, serialization failures require retrying the whole transaction. Do not catch a unique-constraint violation and continue in an already-aborted transaction.
A result row and business write must use the same transaction manager and database. Return the stored result rather than reconstructing it from mutable current entity state. Keep replay headers allowlisted; do not persist cookies, bearer tokens or hop-by-hop headers.
A database transaction cannot atomically include an HTTP payment or email. Write an outbox record with the business mutation and let a retryable worker perform the external effect using the provider's idempotency support. Reconcile uncertain outcomes before retrying irreversible effects. For messages, record a unique consumer/event pair and apply the projection in one transaction; acknowledge only after commit. Retry failed transactions and route poison messages deliberately.
Define retention from the real client retry window. Deleting a key permits a later repeat to
test cases passed, vs 15 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.