VPC endpoint state value parsing is incorrect #619
Comments
imp
added
bug
|
It looks like this same issue is happening for the Go V2 SDK, and a similar problem is happening to SSM in the Rust SDK. There seems to be a pattern among these enums. Internal tracking ID: P66381300 |
jdisanti
added
the
service-api
|
Opened an issue in the aws/aws-sdk which is used to track issues across multiple sdks. Closing this issue |
|
|
This is pretty annoying issue, largely due to the fact that UnknownVariantValue is closed off and only has private fields. Imagine wanting to match on match vpce.state.unwrap() {
// match expected behavior
Available => { do_foo() },
Pending => { do_bar() },
...
// work around this issue
Unknown(variant) => {
let variant = format!("{:?}", variant)};
match variant.as_str() => {
"UnknownVariantValue(\"available\")" => { do_foo() },
"UnknownVariantValue(\"pending\")" => { do_bar() },
_ => { do_baz() }
}
}
_ => { do_baz() }
}Making the value field publicly accessible leads to a much better solution, at least until this is actually fixed. The following is an example. This is no longer tied to a potential change in display functionality for UnkownVariantValue, or the introduction of a new field. match vpce.state.unwrap() {
// match expected behavior
Available => { do_foo() },
Pending => { do_bar() },
...
// work around this issue
Unknown(variant) => {
match variant.value() => {
"available" => { do_foo() },
"pending" => { do_bar() },
_ => { do_baz() }
}
}
_ => { do_baz() }
} |
pub value retrieval for UnkownVariantValue
adds preferred workaround for awslabs#619
|
You shouldn't need to match vpce.state.unwrap() {
// match expected behavior
Available => { do_foo() },
Pending => { do_bar() },
...
// work around this issue
other @ _ => match other.as_str() => {
"available" => { do_foo() },
"pending" => { do_bar() },
_ => { do_baz() }
}
}The unknown variant value is intended to not be used directly, as matching on it could lead to your code breaking in the future. For example, if the SDK didn't yet have a new enum value and you matched on the string value directly, that code would break in the future when an enum variant was added to the SDK for that value. By matching on the enum's string value instead of on the unknown variant value, your code is safe from that. |
|
Yeah, I think I was stuck trying to check against the value in the unknown enum, I hadn't considered just turning unknown enum into a string. Thanks! |
|
Re-opening this issue and closing the tracking issue P66381300 |
Describe the bug
VPC endpoint state values when parsed from their text representation are incorrect. The reason is that code expect them to be in
PascalCase, while in fact they arecamelCase. As a result all the values are getting classified asState::Unknown("xxx").For example
pendingAcceptanceis expected to bePendingAcceptanceavailableis expected to beAvailableetc
Expected Behavior
When running reproduction code below I expect the next output
Current Behavior
Instead every possible VPC endpoint state in
describe_vpc_endpoints()is showed asState::Unknown("text")Reproduction Steps
If you have at least one VPC endpoint
Possible Solution
Additional Information/Context
No response
Version
The text was updated successfully, but these errors were encountered: