You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{
:error,
{
:http_error,
<code>,
%{ body: "<error response body from upstream>", headers: [<header tuples>], status_code: <code> }
}
}
This makes it difficult to rely on dialyzer with ex_aws as the spec omits valid responses.
Additionally, the success response includes the status_code in actual responses, but the provided type includes the body and headers, but not the status_code:
At https://github.com/ex-aws/ex_aws/blob/main/lib/ex_aws/request.ex#L9, the error response is defined simply as
@type error_t :: {:error, {:http_error, http_status, binary}}
However there are code paths (such as https://github.com/ex-aws/ex_aws/blob/main/lib/ex_aws/request.ex#L137) that return non-binary data as the third member of that tuple, such as this abbreviated response I had received:
This makes it difficult to rely on dialyzer with ex_aws as the spec omits valid responses.
Additionally, the success response includes the
status_code
in actual responses, but the provided type includes the body and headers, but not the status_code:Environment
Elixir and Erlang Version
ExAws version (though by inspection is present on newer versions)
Hackney version
Current behavior
Handlers for success and error that include these extra fields are flagged by dialyzer
Expected behavior
The spec includes alternate error shapes, and dialyzer enforces the spec.
The text was updated successfully, but these errors were encountered: