uWSGI harakiri timeouts and client retries: preventing duplicate writes in WSGI handlers

Short answer

uWSGI offers no supported mechanism that stops a retried request from re-invoking your WSGI callable. harakiri only kills the worker after the timeout; it says nothing about what the client, load balancer, or proxy does next, and uWSGI keeps no record of "this request already ran." Idempotency has to live in your application, backed by a database constraint. The lock plugin can serialize concurrent executions but does not provide idempotency, and it is the wrong tool for this problem.

What is confirmed vs. likely

Confirmed behavior: harakiri sends a fatal signal to the worker when a request exceeds the limit, then the master respawns it. There is no hook that marks the request as completed or deduplicates a retry. Any retry — from the client, nginx (proxy_next_upstream), HAProxy, or a browser refresh — arrives as a brand-new request and runs your handler again.

Likely, but verify in your stack: when the worker is killed, the fate of the in-flight database transaction depends on your driver and connection state. In most configurations the TCP connection drops and the database eventually rolls back the uncommitted transaction, but this is not instantaneous and not guaranteed in every driver/pooler combination (for example, a statement that already reached the server and autocommitted, or a pooler holding the session). Do not design around an assumed rollback.

The fix: idempotency at the application layer

1. Have the client generate a unique token per logical operation (a UUID in a header such as Idempotency-Key, or a hidden form field for browser posts).
2. Store the token with the write and enforce uniqueness in the database — a UNIQUE constraint on the token column, plus INSERT ... ON CONFLICT DO NOTHING (PostgreSQL) or equivalent upsert on your database.
3. On conflict, return the original result (or a 200/409) instead of inserting again.

The unique constraint is the actual guarantee; the application check is just a fast path. This survives harakiri kills, proxy retries, double-clicks, and worker restarts, because it does not depend on any uWSGI state.

Answers to your specific questions

1. Deduplication in uWSGI? No documented feature prevents re-execution of the WSGI callable on retry. Request tracking exists for stats and logging, not for suppressing repeats. Application-level idempotency is the only reliable option.

2. Is the transaction aborted on harakiri? Not guaranteed. The worker is killed; the database session is abandoned. Cleanup (rollback of uncommitted work) is normally handled by the server detecting a dead connection, but timing and behavior vary by driver, pooler, and OS. Treat any write that may have reached the database as possibly committed, and let the unique constraint resolve the ambiguity on retry.

3. Is the lock plugin suitable? Not for this. It can serialize concurrent requests sharing a key via an external store (Redis, memcached, file), but it does nothing about a retry that arrives after the first attempt ended — which is exactly the harakiri case. It also adds a hard dependency on the lock backend being reachable. Plugin availability and options vary by build and release; check yours with:

uwsgi --version
uwsgi --plugin lock   # confirm it loads without error

Even where it works, it cannot replace a database-enforced idempotency key.

Verification before you ship

• Set a low harakiri (e.g. 2–3s), make a slow test endpoint insert with a unique token, and have a client retry automatically. Confirm exactly one row results.
• Kill a worker mid-request (kill -TERM <pid>) against a test database and inspect whether the in-flight insert committed, rolled back, or lingered — repeat with your real driver and pooler, since that is the configuration that matters.
• Check that your connection pool discards dead connections so a killed worker does not poison subsequent requests.

One caveat: exact lock plugin options and signal-handling details differ across uWSGI 2.0.x builds and database drivers, so treat the verification steps above as the authoritative answer for your deployment rather than any general claim — including this one.