WSGI idempotency middleware (most options are ASGI-only)

[violetta98]

Hello everyone!

I got tired of rewriting idempotency in every service and getting it slightly wrong, so I packaged it. Posting here because most Python options are ASGI-only, which leaves Flask out.

from flask import Flask
from idemkit import WSGIIdempotencyMiddleware, RedisBackend

app = Flask(__name__)
app.wsgi_app = WSGIIdempotencyMiddleware(
    app.wsgi_app,
    backend=RedisBackend.from_url("redis://localhost:6379"),
)

A client retrying a POST with the same Idempotency-Key gets the first response back and your view doesn't run again. Two identical requests at the same moment: one runs, the other waits for its result instead of erroring.

One honest caveat, because I'd rather say it than have someone find out. The sync path runs on top of an async core through a background event loop. Correct and fine at typical Flask loads, but it's a bridge, not a native sync implementation.

https://github.com/idemkit/idemkit, Apache-2.0

I would appreciate any feedback on it and whether it might be useful for you.

[jbsbda]

Reads like Claude code…?

[davidism]

Yes, and also spammed at a ton of projects. @violetta98 please review https://palletsprojects.com/contributing/llm-ai

[RonnyPfannschmidt]

i'm horrified - that lib messes up vocabulary so bad it needs to be breached off

ensuring exactly once semantics for specific state transition is NOT idempotent - its a precise opposite

to weave the word idempotent into that is a disservice for anyone learning - i'm appalled

what people need for details like charging a order exactly once are structural patterns that ensure transaction conflicts will naturally prevent more than once actions, not a library that slaps the wrong terminology on the wrong place and teaches fire and forget

[violetta98]

Worth correcting the premise first: I don't claim exactly-once. The README says the opposite in as many words: "It gives effectively-once: at-least-once delivery plus idempotent execution, not the impossible exactly-once."

On terminology, an operation is idempotent when applying it twice leaves the same state as applying it once. Two requests carrying the same key produce one charge and the same response, so the state after two is the state after one. RFC 9110 §9.2.2 puts it as "the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request." Google's AIP-155 prescribes the mechanism directly: "if a duplicate request is detected, the server should return the response for the previously successful request."

That's also the vocabulary the people who define this use. The IETF's httpapi working group has a draft for the header itself (expired, 07 October 2025) opening with "can be used to make non-idempotent HTTP methods such as POST or PATCH fault-tolerant", and Stripe draws the method distinction carefully before applying it: "All POST requests accept idempotency keys... [GET and DELETE] are idempotent by definition." If the term is being misapplied here, it's being misapplied the same way by the working group standardising it.

On structural patterns I agree, and that is already what idemkit does internally. Taking the claim is a single conflict-driven write, never a check followed by a write. On Postgres it is literally INSERT ... ON CONFLICT DO NOTHING, a unique constraint doing exactly the conflict prevention you are describing, and the other backends do the equivalent. So the structural pattern isn't the alternative to this, it's the thing underneath it.