+1 to returning 503 for this case, **with** the **Retry-After header** as discussed, so Iceberg REST clients have the expected retry signal for a non-idempotent request.
Small process note: for future API-contract votes, it would be helpful to avoid running most of the vote window over a weekend when possible. This one seems narrow and already discussed, so I do not think it needs to restart, but weekday timing gives more people a practical chance to notice and respond. On Fri, Jul 17, 2026 at 10:42 AM Nándor Kollár <[email protected]> wrote: > +1 (non-binding) > > I think that '503 Service Unavailable' with a 'Retry-After' header > seems like the least bad option to me. > > Thanks, > Nandor > > vignesh a <[email protected]> ezt írta (időpont: 2026. júl. 16., > Cs, 16:44): > > > > Hi all, > > > > Following the recent [DISCUSS] thread [1], I'd like to call a vote on the > > HTTP status code to return when a table or view rename operation fails > with > > TARGET_ENTITY_CONCURRENTLY_MODIFIED. > > > > *Background* 409 Conflict and 429 Too Many Requests were discussed as > > alternatives. However: > > > > - 409 conflicts with the Iceberg REST spec's existing meaning ("target > > identifier already exists"), so clients would misinterpret it. > > - 429 implies rate limiting and carries Retry-After semantics that > don't > > apply here. > > > > The discussion converged on *503 Service Unavailable* as the cleanest > > option - it is retryable and avoids the semantic conflicts above. > > > > *Proposal * Return HTTP *503 Service Unavailable* when a table/view > rename > > fails with TARGET_ENTITY_CONCURRENTLY_MODIFIED. This signals a temporary > > condition that clients can retry. Server-side automatic retries are *out > of > > scope* for this change and can be considered separately later. > > > > My vote: *+1* > > > > Please cast your vote by replying to this thread: > > > > [ ] *+1 / Yes* -- Approve returning 503 [ ] *-1 / No* -- Reject this > > proposal and resume discussion [ ] *0* -- Abstain > > > > This vote will remain open for 72 hours and close at *14:00 UTC on > Sunday, > > 19 July 2026*. > > > > Thanks, *Vignesh* > > > > [1] https://lists.apache.org/thread/tr8zh8121t2jb41s0q2yd9s73y2tp2tq > > > > This change is implemented in PR #4646 > > <https://github.com/apache/polaris/pull/4646> . > > > > -- > Kollár Nándor >
