>From the issue, it looks like we're using 400 for this because that's what the Java client was returning as a generic or unhandled error. I don't think that's a good reason to standardize on 400 now that we are calling out this error in the spec. Why not choose an error code that distinguishes it from a bad request? I think that would be better so that we don't have to rely on checking other fields.
On Fri, Mar 14, 2025 at 9:00 AM Russell Spitzer <russell.spit...@gmail.com> wrote: > +1 > > On Fri, Mar 14, 2025 at 10:17 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> +1 (non binding) >> >> Regards >> JB >> >> On Fri, Mar 14, 2025 at 3:10 PM Eduard Tudenhöfner >> <etudenhoef...@apache.org> wrote: >> > >> > Hey everyone, >> > >> > I'd like to hold a quick VOTE on #12518 that improves the documentation >> around how NamespaceNotEmptyException is treated when a non-empty namespace >> is deleted. >> > In such a case we do return a 400 and we also return a 400 on a bad >> request, thus the client should check the error type to know whether it >> received a NamespaceNotEmptyException. >> > >> > This vote will be open for at least 72 hours. >> > >> > [ ] +1 Improve the documentation in the OpenAPI spec >> > [ ] +0 >> > [ ] -1 I have concerns because ... >> > >> > Kind regards, >> > Eduard >> > >> > >> > >> >
