Hi all,
I've simplified the proposed design for Idempotency-Key support in Polaris
(Iceberg REST spec — retries with the same key must not produce additional
side effects), and I'd like a wider review before updating the
implementation PR (#4269 <https://github.com/apache/polaris/pull/4269>).
What changed
- Before (Model A, lease-based): reserve an idempotency row before doing
work → IN_PROGRESS / heartbeat → finalize after.
- After (Model B, optimistic commit): run the handler first → record only
after a successful (2xx) outcome. The record stores binding + status, not
the HTTP response body. Retries with the same key re-derive an equivalent
response from current catalog state
instead of replaying a stored payload.
The design doc still compares Model A and Model B side-by-side so the
trade-offs are explicit. So far the discussion has been leaning toward
Model B — mutating REST operations only, 2xx-only persistence, no
response-body storage, and the known
trade-offs (e.g. concurrent first-request races; see the NOTES section in
the doc).
Does this direction look right before we lock in the implementation?
Comments on the doc
<https://docs.google.com/document/d/1hqTejVyYXDpL5MJcVc7NyhCslKaGH82QoqMEcUYPvkE/edit?tab=t.0>
or replies on this thread both work.
Thanks,
Huaxin
