VTGate write retries after ambiguous tablet failures risk duplicate non-idempotent DML

Symptom

When a tablet becomes unreachable during a single-statement write (INSERT, UPDATE, DELETE) outside an explicit transaction, VTGate may retry the statement against a healthy tablet after failover. If the original attempt already committed but the client never received confirmation, the retry applies the same write a second time.

Constraints

• Vitess cannot determine whether the first attempt committed when the connection drops before the response returns.
• Automatic retry is only safe for reads or for transactions that never reached the commit phase.
• Non-idempotent statements such as INSERT without a unique key or UPDATE ... SET counter = counter + 1 produce different results on each execution.
• Application-level idempotency (unique constraints, upsert semantics, idempotency tokens) is the documented mitigation.

Open questions

1. Which VTGate flags control the retry eligibility for single-statement DML in the deployed Vitess version, and how do they interact with tablet buffering during reparenting?
2. For a workload that cannot add unique keys to every table, what is the recommended pattern to detect and suppress duplicate writes caused by ambiguous-commit retries?
3. Does Vitess expose any signal (error code, session state, or callback) that lets the application distinguish "definitely not committed" from "outcome unknown" so it can decide whether a client-side retry is safe?