Duplicate writes on Vercel Serverless Function retries despite Idempotency-Key usage

The goal is to achieve exactly‑once semantics for side‑effects (e.g., writes to a database or KV store) when a Vercel Serverless Function is retried by a client after a transient network error or 5xx response.

Vercel treats each retry as a new invocation with a distinct request ID, so without application‑level guards the same logical request can trigger multiple writes. Common patterns include checking the Idempotency-Key header, storing the key in a short‑lived store, or using Edge Middleware to return a cached response before the function runs. However, proxies may strip or alter custom headers, Edge Middleware adds latency, and ISR background revalidation retries are opaque, making it unclear which strategy provides the strongest guarantee while preserving observability and performance.

What is the most reliable way to detect and skip duplicate processing when the Idempotency-Key header might be modified or removed by intermediaries? Can Edge Middleware be configured to deduplicate retries without noticeably increasing latency for fresh requests? How can developers confirm that ISR background revalidation does not lead to duplicate writes to external stores?