amogh-jahagirdar commented on code in PR #14196:
URL: https://github.com/apache/iceberg/pull/14196#discussion_r2400619934
##########
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 don't think the spec should get in the business of defining a required
UUID format of the key.
My mental model at least is that these keys are effectively any UUIDs
generated by the client under certain conditions, and the server can either
choose to say "Yeah I can work with that structure and dedupe" or "No, this is
not allowed".
If a client can generate these V7 UUIDs, and a server can handle it that's
great. If the client cannot generate these newer UUIDs, but a server can handle
it within the other requirements of this spec that's great. If a server cannot
handle it, it would reject the request. Keeping the spec open that way, allows
for different components to evolve as desired while still being able to derive
the most value out of this proposal.
--
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]
