Hi Nandor, Good question :)
I did not read the PR yet, but my gut feel is towards the 409 error code because 5xx generally means a fundamental issue with the service that goes beyond the scope of client requests. In a more general perspective, traditional HTTP status codes are often too narrow to express all the API minute error details. My personal view is that a rich payload object in the response can be useful in such cases... but again that will require a spec change. That said, if the request does not require additional client input for a retry, Polaris should retry. I assume we can refactor the code to clearly distinguish retryable and non-retryable failures on the server side. That part should not require spec changes. Cheers, Dmitri. On Mon, Jun 8, 2026 at 9:48 AM Nándor Kollár <[email protected]> wrote: > Hi all, > > I'd like to ask for the community's opinion on the appropriate > response status code for table/view rename operations when there is a > conflicting operation in progress. > > A PR was recently raised [1], which I believe highlighted the question > of what the correct status code should be in such conflict scenarios. > To me, the Iceberg REST Catalog specification does not clearly address > this case. Neither 409 Conflict nor 503 Service Unavailable seems > entirely appropriate for indicating to the client that the operation > could not be completed due to a conflict and that retrying the > operation may succeed. > > I think 409 Conflict might be the better choice, but that would > require a change to the specification. It would also end up serving > two different purposes: a non-retriable scenario, where the target > name is already reserved, and a retriable scenario, where the > operation failed due to a temporary conflict. What do you think? > > [1] https://github.com/apache/polaris/pull/4646 > > Thanks, > Nandor >
