How can I make use of the generated_sdk::Error type?

[skeet70]

I have code that calls aws_sdk_kms encrypt and decrypt. Those return SdkError<EncryptError, Response> and SdkError<DecryptError, Response>. I've written unified code to convert SdkError<Error, Response> into my application's error hierarchy. How can I get SdkError<T, Response> -> SdkError<Error, Response> where T: Into<Error>?

I've tried to write this, but as far as I can tell the SdkError::ServiceError case can't be constructed. You can only get borrows of the source and raw inside (which don't implement clone), or ownership of one of the two (to be provided to SdkError::service_error(original_e.into(), original_raw). The forced _ case (because of the non_exhaustive flags involved) also seems impossible to implement to me, and I have it as unimplemented for now in the hopes it isn't triggered.

This seems like it would be a common usecase, but maybe I'm approaching it incorrectly? The end goal is an impl From<SdkError<Error, Response>> for ApplicationError.

[jdisanti]

SdkError has an into_service_error() function that will convert it into the error type for the operation you called (for example, EncryptError for the Encrypt operation). Then the Error type at the crate root implements From for every one of these service error types.

So essentially, you can do something like this:

match call_kms_encrypt().await {
    Ok(success) => { /* do success stuff */ },
    Err(err) => aws_sdk_kms::Error::from(err.into_service_error())?,
}

Where your ApplicationError implements From<aws_sdk_kms::Error>. At that point, you're only dealing with conversion of one error type.

Edit: Actually, it's even simpler than that. aws_sdk_kms::Error already implements From<SdkError> for all the different error types. So you can simply do:

match call_kms_encrypt().await {
    Ok(success) => { /* do success stuff */ },
    Err(err) => aws_sdk_kms::Error::from(err)?,
}

[jdisanti]

I still need to handle dispatch/construction/timeout errors.

I want to know more about why you need to handle these kinds of error separately. From my viewpoint, the SDK retries failed requests and refreshes expired credentials automatically, so when and unhandled error occurs, there isn't really anything actionable left to do other than log the error. But maybe there's a use-case we've overlooked.

From the code you posted above, it looks like you're treating the SdkError::ConstructionFailure as a configuration error, which isn't quite accurate. This error only happens if the SDK failed to convert the given input into a serialized payload it can send to AWS. For the most part, this happens when a field is missing from the input that goes into the URL for the HTTP request. Otherwise, it's likely a serialization bug in the SDK, or an extreme edge case (such as a date-time 50,000 years from now being serialized). It's an unusual error that shouldn't need to be handled separately from other unhandled errors.

Another (semi-related) unclear thing to me is where in this whole hierarchy authorization issues end up.

I think these end up in SdkError::DispatchFailure if credential loading failed, and in SdkError::ResponseError if the signed request is rejected by the remote server. There isn't an easy way to separate them from the other errors that can end up in those categories though. These aren't really actionable errors though since the credentials provider is responsible for credential refresh.

[skeet70]

Our particular use case is a docker container that makes calls to multiple tenant's cloud KMS providers using end-to-end encrypted credentials. So from our viewpoint:

• for auth errors
  • we don't know if the credentials were valid in the first place, so we may get 403 or something along those lines back from you
  • we don't know if the credentials have stayed valid (i.e. IAM permissions for the given credentials were revoked or altered to be broken accidentally)
• for other "unactionable" errors: just because the failed request was retried automatically, doesn't mean we don't need to know what the failure was. It may be that the caller should try again themselves at a different time or after taking some action on their part. We the caller (or in our case our caller) have more semantic information about the context of the original request than the SDK can have, and expect to get information from the SDK about how things failed so we can make decisions using that context about what actions to take going forward. Even if they're actions that no longer involve the SDK, it's valuable information. I don't think any of the things falling outside of service_error are actually not actionable from a broader context like this, and some of the things that aren't split out in the current categories would additionally be useful for us to action on.

It's particularly strange moving from Rusoto (which I understand was unofficial, and not a target) to this and losing credential and authorization error information.

[jdisanti]

Thank you for the feedback! It seems to me like we should take another hard look at errors to better serve these use-cases. Since we have an RFC in progress on improving error ergonomics, I'll take a stab at incorporating this into it.

[skeet70]

Great, thanks, I'll keep an eye on it. For now it seems like the best I can do is check if a DispatchFailure is_user and make some educated guesses? The source isn't exposed that would let me tell them what the actual problem was, and ResponseError doesn't expose the source in any way, even abstractly, so I can't figure out if was rejected entirely or the response wasn't parse-able JSON or something.

[jdisanti]

You should be able to get at the source using the standard library's Error::source function, and it is possible to inspect the result of that by downcasting.

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.

[vikigenius]

@jdisanti Has there been any more thought put into this? I would also like to be able to easily/ergonomically propagate the contextual information such as Timeouts and Auth errors.