Hi Huaxin, Thanks for resuming this proposal!
In general, I suppose the intention is to implement the recently approved Iceberg REST Catalog spec change for Idempotency Keys. With that in mind, I believe the Polaris proposal probably needs to be more focused on the server side implementation now that the API spec has been finalized. I do not think Polaris needs any other API changes in the REST Catalog on top of the Iceberg spec. I'd propose to deal with the REST Catalog API first and then extend to the Management API (for the sake of simplicity). I added some more specific comments in the doc, but overall, I believe we need to consider what needs to be changed in the java Persistence API in Polaris because the idempotency feature probably applies to all backends. Also, as I commented [1] in earlier emails about this proposal, I believe some synergies can be found with the async tasks framework [2]. The main point here is orchestrating request execution among a set of distributed server nodes. [1] https://lists.apache.org/thread/28hx9kl4qmm5sho8jxmjlt6t0cd0hn6d [2] https://lists.apache.org/thread/gg0kn89vmblmjgllxn7jkn8ky2k28f5l Cheers, 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 >
