snazy commented on code in PR #4659: URL: https://github.com/apache/polaris/pull/4659#discussion_r3426629927
########## CHANGELOG.md: ########## @@ -52,6 +53,7 @@ request adding CHANGELOG notes for breaking (!) changes and possibly other secti - Added support for `register table` overwrite semantics in the Iceberg REST catalog flow (`overwrite=true`) for internal Polaris catalogs. With overwrite enabled, existing table pointers can be updated to a new metadata location while preserving default behavior for `overwrite=false`. - Added `REGISTER_TABLE_OVERWRITE` authorization operation mapped to `TABLE_FULL_METADATA` for deterministic overwrite authorization. - Added Polaris Spark 4.0 client. +- Added handler-level support for the Iceberg REST `Idempotency-Key` header on `createTable`, using an optimistic-commit model: the terminal outcome is recorded only after a successful (2xx) response and retries replay an equivalent response rebuilt from current catalog state (no response body is stored). The key is bound to the request-derived resource (operation, namespace, name and access-delegation modes) and the caller principal, so reusing a key for a different resource or by a different caller is rejected with HTTP 422. A retry that loses a concurrent create race replays the winning request instead of returning 409, and a replay returns 422 if the table has advanced beyond the originally-created state. Only successful outcomes are recorded — a retry after a failure simply re-runs the operation. Idempotency is disabled by default and configured under `polaris.idempotency`; records are kept in a standalone idempotency store decoupled from the metastore persistence. Review Comment: ```suggestion - Added experimental, disabled-by-default handler-level support for the Iceberg REST `Idempotency-Key` header on `createTable`. Polaris records successful outcomes only after `createTable` completes and rebuilds retry responses from current catalog state; it does not store response bodies or prevent duplicate in-flight execution. Concurrent create retries can replay the matching successful create if its idempotency record becomes visible within a bounded lookup window; otherwise the original 409 conflict is returned. Failed outcomes are not recorded, so retries after failures re-run the operation. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
