rmannibucau commented on PR #4646: URL: https://github.com/apache/polaris/pull/4646#issuecomment-4688812925
I'll just write it for the record since you kind of converge but I still think this lead to a wrong behavior on the client side: * 503 is used to notify the client the *server* is down or overloaded, this means this is cacheable per client/application (understand not per entity) on the client side, this is totally wrong there * 429 has some underlying semantic of retries (using headers or a default - often an exp backoff) * I understand the issue you point with 409 but from a client perspective it is not an issue at all IMHO * 412 can be a work around breaking less the client and gateways IMHO if really an issue (but think iceberg can be pinged to refine the 409, there is no valid reason it is not used there) Another thing to consider I think is that if the management of the mutations is implemented as a queue internally (potentially distributed but let's stick to the design) then you never have this ambiguity and plain iceberg status are fine (409, 404 mainly there), so maybe the question is not which status but more how to implement it right - think polaris can just delay the response to the previous execution "end" somehow. The overall concern is using a semantic the client and gateways/proxies know and associate it another meaning leading to a wrong behavior (the 503 global cache - think circuit breakers - is a good example of that). -- 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]
