Hi Fabio! Thanks for starting this thread!
Just to clarify my GH comments: I think we need to consider table and namespace updates separately. As far as namespace updates are concerned, my reading of the Iceberg REST Catalog API spec is that the spec does not define anything about conflicts. It is written in a way that I tend to interpret such that the latest namespace property update wins. What is "latest" is up to the server implementation. Under that interpretation, I'd say Polaris should NOT produce 409 responses for concurrent Namespace updates, but attempt to retry and still apply the requested changes. This is technically possible to implement in a non-conflicting manner on the server side. If retries timeout, Polaris could still respond with a 409, but existing Iceberg java clients will interpret those replies as "namespace already exists". So I believe Polaris should avoid that situation. I'd propose 429 (Too Many Requests) in this case. It may not be interpreted correctly by the existing Iceberg java code, but at least it is meaningful from the HTTP perspective. If this is accepted by the community it might be worth amending the Iceberg REST spec to explicitly mention this response code. 422 (Unprocessable Content) is already supported by the Iceberg java client [1] but the end result is the same as for 429. My preference is 429 because 422 is effectively non-retriable from the HTTP perspective, but timeouts caused by concurrent load are retriable. I originally suggested 504 (Gateway Timeout) in GH. This is still a viable option from my POV. The "gateway" here can be liberally interpreted at the Polaris storage layer. [1] https://github.com/apache/iceberg/blob/e47e99a0dd3a500134633df640522c8c8fb56a2b/core/src/main/java/org/apache/iceberg/rest/ErrorHandlers.java#L187 Cheers, Dmitri. On Wed, Jul 16, 2025 at 11:17 AM Rizzo Cascio, Fabio <fabio.rizzocas...@jpmorgan.com.invalid> wrote: > Hi all, > > > > While working on Issue #1390<https://github.com/apache/polaris/issues/1390>, > what initially seemed like a quick fix has turned into a more complex > problem. Following Dimas-b's suggestion, I'm opening this up for a wider > discussion. > > You can see the comments on my PR #1989< > https://github.com/apache/polaris/pull/1989>. > > I have a couple of questions: > > 1. If multiple property updates are coming in concurrently and they > don't update the same key, should we merge the properties (entity coming in > the request and the entity refreshed) and make the update? > 2. If multiple updates are coming in concurrently and they are trying > to update the same property key value, should we throw an exception? What > error code should we return? > > I look forward to your thoughts. > > > > Thanks, > > > > Fabio > > This message is confidential and subject to terms at: > https://www.jpmorgan.com/emaildisclaimer including on confidential, > privileged or legal entity information, malicious content and monitoring of > electronic messages. If you are not the intended recipient, please delete > this message and notify the sender immediately. Any unauthorized use is > strictly prohibited. >
