singhpk234 commented on code in PR #14196:
URL: https://github.com/apache/iceberg/pull/14196#discussion_r2397526966
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1903,6 +1926,35 @@ 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 an equivalent final response
without re-running the
+ operation (the response body may be rebuilt from current authoritative
state and need not
+ be byte-identical).
+
+ Finalization rules:
+ - Finalize & replay: 200, 201, 204, and deterministic terminal 4xx
+ - Do not finalize (not stored/replayed): 5xx, 409
(RequestInProgressException)
+
+ Key Requirements:
+ - Key format: UUID (V7 preferred)
+ - Scoped to operation type and resource path; the idempotency key must
be unique per (operation type, resource path) pair (e.g., updateTable on db.t1)
+ - Catalogs may expire keys according to the advertised token lifetime.
Review Comment:
Can we say this :
```suggestion
- Catalogs MUST NOT expire keys before the end of the advertised
token lifetime.
```
Mostly to avoid confusion that a catalog can expire keys early, my
understanding here is, we use MAY here because catalog can give grace time as
mentioned below so >= advertised token lifetime hence to explicit suggesting
negation < advertised token lifetime
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1966,6 +2018,18 @@ components:
"GET /v1/{prefix}/namespaces/{namespace}/tables/{table}",
"GET /v1/{prefix}/namespaces/{namespace}/views/{view}"
]
+ idempotency-key-lifetime:
+ type: string
+ format: duration
+ description: >
+ Client reuse window for an Idempotency-Key (ISO-8601 duration,
e.g., PT30M, PT24H).
+ Interpreted as the maximum time from the first submission using a
key to the last retry
+ during which a client may reuse that key. Servers SHOULD accept
retries for at least this
+ duration and MAY include a grace period to account for
delays/clock skew. Clients SHOULD NOT
+ reuse an Idempotency-Key after this window elapses; they SHOULD
generate a new key for any
+ subsequent attempt. Presence of this field indicates the server
supports Idempotency-Key
Review Comment:
Lets say a client retried n times before, was suppose to retry n+1 th time
but before it could retry the window expired, there can 2 cases :
1. n th try succeeded
2. n th try fail
n th try failing and we generating new idempotency key for n + 1 th attempt
should be fine, but in case when n th try succeeded and we created a new
idempotency key, we treat this is as a new request ? we can then self conflict
?
would it better to fail with commit state unknown here ?
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -4574,6 +4634,23 @@ components:
}
}
+ IdempotencyInProgressResponse:
Review Comment:
Are we referencing this response some where ?
--
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]
