Head response status code is overriden by the default one
Actual behavior
Given following smithy definition:
@http(method: "HEAD", uri: "/cities/{cityId}/weather")
@readonly
operation HeadWeather {
input := {
@required
@httpLabel
cityId: CityId
}
output := {
@required
@httpResponseCode
statusCode: Integer
}
}
and the endpoint implementation:
def headWeather(cityId: CityId) : IO[HeadWeatherOutput] = IO(HeadWeatherOutput(404))
when querying the server it returns:
$ curl --head localhost:8080/cities/123/weather 12:08:48
HTTP/1.1 200 OK
Date: Mon, 05 Feb 2024 11:08:51 GMT
Connection: keep-alive
Content-Type: application/json
Transfer-Encoding: chunked
Expected behavior
It should return response with 404 status code.
Additional notes
full reproduction: https://github.com/ghostbuster91/demos/tree/head-status-code used to work in 0.17.x series (tested against 0.17.16 and 0.17.18) doesn't work in 0.18.x series (tested against 0.18.0, 0.18.1 and 0.18.7)
relevant: https://github.com/disneystreaming/smithy4s/issues/1145
Right, this has nothing to do with whether the http method is HEAD.
The reason it doesn't work is this filter : https://github.com/disneystreaming/smithy4s/blob/f3f28fc78e4ff41c2aff5517cbea183c31296fbc/modules/core/src/smithy4s/http/HttpResponse.scala#L119
Now that being said, I'm not sure I'm willing to change the behaviour to support the example you share, although it used to match your expectations in previous version. I do think it makes sense for a successful response (that is defined in the output member of the smithy operation) to not return a status code that represent an error. In particular because it could throw-off generated clients.
To expand I think the correct behaviour should be that the status code set dynamically in the @httpResponseCode annotated-field should follow the 2xx range if the field is used in the output, the 4xx range if the field is used in a @error("client") structure, and the 5xx range if the field is used in a @error("server") server structure.
I'm not the authority on questions related to behaviour of traits from smithy.api. I've opened an issue on the official smithy repo to ask the question, and I'll align the behaviour of smithy4s on what they say.
I see, thanks for the clarifications, using non error status code indeed works without any issues.