AWS KMS SDK ThrottlingException isn't surfaced

[skeet70]

trafficstars

Describe the feature

Add a ThrottlingExcepton type to the KMS SDK.

Use Case

We'd like to use the library (with retries turned off) so we can surface that the caller of our code is being throttled and let them deal with it however they'd like to. Our particular use case is symmetric encrypt/decrypt operations, which have a combined limit of 50000 op/s, which is hard for us to test locally.

Proposed Solution

Add support for ThrottlingException to the KMS SDK, which is an existing error type on several other SDKs.

Other Information

According to KMS docs, KMS endpoints can return ThrottlingException. That kind doesn't exist in the KMS Error type and as far as I can tell reading the code isn't surfaced by any of the above layers (general smithy stuff or retries).

Acknowledgements

• [X] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

A note for the community

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue, please leave a comment

[Velfi]

Hey @skeet70, thanks for submitting this issue. The service team hasn't gotten around to modeling this error variant so we filed an issue with the KMS team. Luckily, there's no need for you to wait. When a service sends an SDK client an error that isn't modeled, we deserialize it to an Unhandled variant. In your case, you should be able to call the .code() method on the throttling error and see if it's ThrottlingException. I imagine the code would look something like this:

let res = <your encrypt opertation>.send().await;

if let Err(err) = res {
  if err.code() == Some("ThrottlingException") {
    // handle throttling errors
  } else {
    // handle other kinds of errors
  }
}

Let me know if that approach works for your use case.

[github-actions[bot]]

Greetings! It looks like this issue hasn’t been active in longer than a week. We encourage you to check if this is still an issue in the latest release. Because it has been longer than a week since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or add an upvote to prevent automatic closure, or if the issue is already closed, please feel free to open a new one.

[skeet70]

I haven't had a chance to come back and try the workaround yet, but since the code is preserved in the Unhandled variant that will likely work for us for now while we wait for a real error variant.

[jmklix]

Opened an issue in aws/aws-sdk which is used to track issues across multiple sdks. Closing this issue

[github-actions[bot]]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.

[skeet70]

@jmklix I couldn't find the issue created there, could you provide a link to it?