Closed pboguslawski closed 1 year ago
Interesting, original source of mapping is https://github.com/googleapis/googleapis/blob/f36c65081b19e0758ef5696feca27c7dcee5475e/google/rpc/code.proto#L127, I wonder was it a mistake in google repo or deliberate decision.
Seems that FAILED_PRECONDITION
description in googleapis is not well mapped to HTTP status code (400 means client side problem) or they have some reason for merging different 4xx errors into one 400.
Consider replacing 400->412 in swaggest for status.FailedPrecondition
to allow API clients to distinguish failed preconditions (i.e. client tried to update resource with lost update protection detection and update failed) from bad client requests (i.e. invalid argument that may indicate bug in client).
After this mod, when 304 is added to possible error responses with...
u.SetExpectedErrors(status.Internal, rest.HTTPCodeAsError(http.StatusNotModified))
...openapi.json contains non-empty body for 304 but should not.
Describe the bug
status.InvalidArgument
andstatus.FailedPrecondition
are different statuses but are mapped to the samehttp.StatusBadRequest
:https://github.com/swaggest/rest/blob/master/error.go#L130 https://github.com/swaggest/usecase/blob/master/status/status.go#L97
Expected behavior
status.FailedPrecondition
should be mapped tohttp.StatusPreconditionFailed
.Additional context Related: #145