huaxingao commented on code in PR #14196:
URL: https://github.com/apache/iceberg/pull/14196#discussion_r2456073912
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1903,6 +1926,34 @@ components:
schema:
type: string
+ idempotency-key:
+ name: Idempotency-Key
+ in: header
+ required: false
+ schema:
+ type: string
+ format: uuid
+ minLength: 36
+ maxLength: 36
+ example: "550e8400-e29b-41d4-a716-446655440000"
+ description: |
+ Optional client-provided idempotency key for safe request retries.
+
+ When present, the server ensures no additional effects for requests
that carry the same
+ Idempotency-Key within the same operation/resource scope. If a prior
request with this key
+ has been finalized, the server returns the previously finalized
response instead of
+ re-executing the mutation.
+
+ Finalization rules:
+ - Finalize & replay: 200, 201, 204, and deterministic terminal 4xx
+ - Do not finalize (not stored/replayed): 5xx, 409 request_in_progress
+
+ Key Requirements:
+ - Key format: UUID (V7 preferred)
Review Comment:
I have checked other implementations and standards. The UUID version appears
to be an implementation detail.
Stripe’s [docs](https://docs.stripe.com/api/idempotent_requests) say:
```
A client generates an idempotency key, which is a unique key that the server
uses to recognize subsequent retries of the same request. How you create unique
keys is up to you, but we suggest using V4 UUIDs, or another random string with
enough entropy to avoid collisions. Idempotency keys are up to 255 characters
long.
```
The [IETF idempotency-key
draft](https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/)
likewise recommends using `a UUID [RFC4122] or a similar random identifier,`
without prescribing a specific version.
Given this, I don’t think the Iceberg REST spec should mandate UUIDv7 or
define server behavior around it. Let’s require a UUID string (RFC 9562 textual
form) and not specify a specific version or server logic tied to UUID internals.
I’d like to conclude the UUID discussion here. For implementation details,
we can continue the discussion in the [Polaris idempotency
proposal](https://docs.google.com/document/d/1L5A8Cspugsk1dW4Ij4dy5wB5FKa8KnaXT0LHBJdgq9w/edit?tab=t.0#heading=h.ecn4cggb6uy7).
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
