ex-aws / ex_aws

So I'm currently experimenting with AWS Timestream. The ex_aws_timestream repo works fine, but when there is a RejectedRecordsException, there seems to be no way of getting the index of the failed record.

This seems to be caused by this line

ex_aws/lib/ex_aws/request.ex

Line 152 in 903eed1

def handle_aws_error(type, message, _) do

that does not return any error details.

The plain response looks like this:

{:ok, 419,
 [
   {"x-amzn-RequestId", "..."},
   {"Content-Type", "application/x-amz-json-1.0"},
   {"Content-Length", "370"},
   {"Date", "Fri, 20 May 2022 15:01:56 GMT"},
   {"Connection", "close"}
 ],
 "{\"__type\":\"com.amazonaws.timestream.v20181101#RejectedRecordsException\",\"Message\":\"One or more records have been rejected. See RejectedRecords for details.\",\"RejectedRecords\":[{\"ExistingVersion\":1,\"Reason\":\"A record already exists with the same time, dimensions, measure name, and version 1. A higher version is required to update the measure value.\",\"RecordIndex\":17}]}"}

ex_aws only returns {:error, {"RejectedRecordsException", "One or more records have been rejected. See RejectedRecords for details."}}

Environment

Elixir & Erlang versions (elixir --version): Elixir 1.13.4 (compiled with Erlang/OTP 24)
ExAws version mix deps |grep ex_aws: ex_aws 2.3.2
HTTP client version. IE for hackney do mix deps | grep hackney: hackney 1.18.1

Current behavior

There is no way to get any error details.

Expected behavior

ex_aws should provide a way to access error details.

The problem here is that we have a common error handling system for all services, even though they can all return different service-specific error info. We currently have a couple of special-case handlers, but really the handling should be delegated to the service that made the request in the first place.

What I'd like to do to resolve this is allow the service module to define a particular callback, and have the generic error handler look for that and call it if it exists (falling back to the existing defaults if it doesn't). I envisage this being done by adding an optional service_callback_module field to the Operation structs which is then checked by handle_aws_error for the required callback (I say "optional" only so that it could be added a service at a time without breaking compatibility). That would also make it nicely extensible for any other service-specific post-request functionality we wanted to add down the road.

This feature is now available as of 2.4.0. See #902

Unable to get error details

Environment

Current behavior

Expected behavior