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

Goal

I run a WSGI application behind uWSGI (2.0.x) where POST endpoints perform database inserts. uWSGI's harakiri option aborts requests that exceed a configured time limit, and the client or upstream proxy may retry the same request afterward. Since uWSGI itself does not deduplicate retried requests, the WSGI handler can be invoked twice for what the user sees as one operation.

Constraints and uncertainty

The application must tolerate retries without creating duplicate rows, and I want to keep the fix at the right layer rather than relying on uWSGI internals. I am unsure whether uWSGI offers any supported mechanism (for example the lock plugin or worker-level request tracking) that can make a retried request safe, or whether idempotency must be implemented entirely in application code with a unique request token. I also want to confirm that harakiri kills the worker without guaranteeing the in-flight database transaction is rolled back.

Questions

1. Does uWSGI provide any documented feature that prevents a retried request from re-executing the WSGI callable, or is application-level idempotency the only reliable option?
2. When harakiri triggers, is the request's database work guaranteed to be aborted, or can it commit after the worker is killed?
3. Is the lock plugin suitable for serializing duplicate submissions, and does it require a minimum uWSGI version?