Hi Huaxin, The current version of the Polaris proposal has this text in the Motivation section:
Naïvely retrying can: [...] Trigger client‑side cleanup for a commit that actually succeeded (breaking referential integrity and corrupting snapshots). I do believe that the Idempotency Key feature (even if implemented) will not prevent this failure scenario completely. It may be able to reduce its probability, but the basic problem of erroneous client-side clean up is still possible. For example, all responses and retry messages may appear to be lost from the perspective of one client, but the server might still be able to successfully execute the commit. Subsequently, other clients may be able to read the new state of the table from the server. If you agree with that problem statement, listing this use case as a "Motivation" might be giving false assurance to the reader. It may be best to avoid listing this use case or at least clarify that we're talking about reducing the probability of errors, without solid guarantees. WDYT? I believe I commented about that before, but I'm unable to find my old comment :) Thanks. Dmitri. On Sat, Nov 22, 2025 at 7:50 PM huaxin gao <[email protected]> wrote: > Hi all, > I would like to restart the discussion on Idempotency-Key support in > Polaris. This proposal focuses on Polaris server-side behavior and > implementation details, with the Iceberg spec as the baseline API contract. > Thanks for your review and feedback. > > Polaris Idempotency Key Proposal > < > https://docs.google.com/document/d/1ToMMziFIa7DNJ6CxR5RSEg1dgJSS1zFzZfbngDz-EeU/edit?tab=t.0#heading=h.ecn4cggb6uy7 > > > > Iceberg Idempotency Key Proposal > < > https://docs.google.com/document/d/1WyiIk08JRe8AjWh63txIP4i2xcIUHYQWFrF_1CCS3uw/edit?tab=t.0#heading=h.jfecktgonj1i > > > > Best, > Huaxin >
