awslabs / awslabs/aws-sdk-rust
Cloudformation - DescribeStacksErrorKind only contains "Unhandled"
- Dominant language
- Rust
- Stars
- 3.3k
- Forks
- 290
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 3
Description
### Describe the bug
The [DescribeStacksErrorKind](https://github.com/awslabs/aws-sdk-rust/blob/31cfae2cf23be0c68a47357070dea1aee9227e3a/sdk/cloudformation/src/error.rs#L3858-L3861) only contains the value "Unhandled", and it is necessary to match against the error string to decide how to respond to an error. For instance, a quick way to check if a stack exists is to use this call to list, filtering for the given stack name, and then checking that the error returned indicates the stack doesn't exist.
### Expected Behavior
The known responses to be parsed out and exposed as different `kind`s to avoid the caller having to do this themselves (like the other APIs?)
### Current Behavior
Code like this:
```rust
return if e.to_string().contains("does not exist") {
Ok(false)
} else {
// This is less great
...
}
```
### Reproduction Steps
call DescribeStacks and try and parse the response
### Possible Solution
Parse the response out to the different types within the SDK
### Additional Information/Context
_No response_
### Version
```text
0.21.0
```
### Environment details (OS name and version, etc.)
osx 12.5.1
### Logs
_No response_
Contributor guide
Research direction
Start in sdk/cloudformation/src/error.rs around DescribeStacksErrorKind and inspect how DescribeStacks responses are represented. Compare the handling with other APIs mentioned in the issue, then identify the known error responses that should be exposed as distinct kinds. Done means callers can distinguish the relevant responses without matching error strings.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, rust
- Domain
- api, cloud
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100