Consul KV Idempotency Under Service Mesh Retry Rerouting

When Consul service mesh health checks trigger request retries, the underlying HTTP layer may re-invoke downstream service calls without preserving the Consul session identifier and prior write index that guarantee idempotent KV operations.

The documented Compare-and-Swap pattern requires the caller to supply both the session ID and the index from the previous successful write; if either is omitted or stale, Consul may accept the operation as a new write, risking duplicate data or lost updates. This creates an interoperability question between the mesh's retry semantics and the KV store's session-bound idempotency model.

The precise goal is to determine whether a retryed request automatically carries forward the original session context, or if the application must explicitly re-establish it before each mesh-retryed invocation, and what the failure mode is when session expiry precedes write acknowledgment.

• Under what conditions does a Consul service mesh retry preserve the session ID and prior write index required for CAS-based idempotency?
• If the mesh reroutes a request without that context, does the KV store reject the write, accept it as a duplicate, or treat it as a new entry?
• Are there configuration or protocol mechanisms within the mesh or KV client libraries that enforce session continuity across retries, or must idempotency be enforced entirely at the application layer?