Missing AttachmentStatus Available For Internet Gateways

[tlm]

Describe the bug

The InternetGatewayAttachment struct here https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/ec2/types#InternetGatewayAttachment has an State field for the status that reports "available".

However in the provided enums here https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/ec2/types#AttachmentStatus there is no enum for "available".

It would be nice to get a strongly typed enum from the API to rely on for checking the value.

Expected Behavior

A typed enum for the value returned from the AWS api.

Current Behavior

No enum currently provided.

Reproduction Steps

N/A

Possible Solution

No response

Additional Information/Context

No response

AWS Go SDK V2 Module Versions Used

v1.111.0 of github.com/aws/aws-sdk-go-v2/service/ec2/types

Compiler and Version used

1.20.0

Operating System and version

darwin

[RanVaknin]

Hi @tlm ,

Im not sure where you see that available is in fact a valid enum type for AttachmentStatus.

The EC2 docs only specify the 4 types (that are currently correctly modeled).

If you are able to make requests with sending available as a valid state, meaning there's service side behavior that supports it, this will be a feature request for the EC2 service team, not the SDK team.

If you didn't know, all the SDKs are code generated from the model of each AWS service. If the upstream model doesn't contain that information, then the SDK wont have that information either.

I suggest you use the AWS console to open a support ticket and ask to raise this as a feature request to the service team.

I'm going to leave this issue open in case you need to clarify something or have additional question, but as it stands, this ticket is not actionable from the SDK team's perspective. Otherwise feel free to close this.

Thanks,
Ran~

[tlm]

Thanks @RanVaknin,

The docs you linked to actually state the problem perfectly.

The current state of the attachment. For an internet gateway, the state is available when attached to a VPC; otherwise, this value is not returned.

and then:

Valid Values: attaching | attached | detaching | detached

Both the statements in the docs are in contradiction to one another.

What we see being returned from the API is available. But unlike the rest of the state fields in the package this field is not modeled anyway. It's trivial to make the enum on the consuming side but would be nice to have a strong type to rely on from the library like all the other state/status fields.

[RanVaknin]

Hi @tlm

Thanks for the clarification. I totally agree with you, but as I mentioned this needs to be modeled correctly to be reflected in the SDKs. Usually with bigger modeling issues we cut a ticket to service team but this is an involved and strenuous process. Since the workaround is straightforward (specifying the string "available") I don't think it's something that we can prioritize at the moment.

Im going to move this to the cross SDK repo, if it gains engagement (+1 upvotes / comments) we can prioritize this effort.

Thanks again for your help.
All the best,
Ran~

[ashishdhingra]

P124948296

[ashishdhingra]

@tlm I have opened an internal ticket with the service team. Would post any updates here as I get them, and would close this issue once it is in the service team's backlog.

[ashishdhingra]

Service team is investigating the issue.

[ashishdhingra]

Service team is still evaluating if adding Available to AttachmentStatus enum would be a breaking change and if it would pollute other services which share the enum with unnecessary status. As of now, there is no ETA for the change. Since the issue is already with the service team, closing this ticket. If the value Available is added to the enum in future via model updates, it would propagate to downstream SDK(s) automatically.

[github-actions]

This issue is now closed.

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.

[gravitylow]

Hey all, so unfortunately due to how these structures were originally created and used, we do not have a good way to introduce this change without creating backwards-incompatible changes for someone.

In short, the AttachmentStatus enum is currently re-used by a bunch of other EC2 APIs and resources in addition to the Internet Gateway structure. For example the AttachmentStatus used by InstanceNetworkInterfaceAttachment, EbsInstanceBlockDevice, and VpcAttachment are all the same enum. This is not good practice but now that it's done, it's done, and we can't change the enum used by one or more of them to differentiate them without breaking strongly-typed SDKs.

We could add the available status to the shared enum, but this would also add the value to these other usecases where it is not valid and may cause more confusion and/or need to be accounted for by SDK users' switch statements and the like.

We could also switch just the Internet Gateway's type to a dedicated enum other than AttachmentStatus, since that enum doesn't accurately represent the states returned by the API, however given that this will be a breaking change, we're not convinced at this point that it's worth making compared to the value it provides.

The other alternative is obviously updating the actual value returned by the Internet Gateway APIs to use attached or one of the existing values that are enumerated in the SDK, but again this has the potential to be backwards-breaking, especially since this behavior is more than 10 years old.

So, all in all, our guidance in this situation has to be to disregard the AttachmentStatus enum and simply maintain available as a constant value to check for. That's the only possible value for this field, and although it seems weird, given how long the behavior has been in place I can assure you it won't be changing any time soon. If anyone has a better proposal for how to handle this scenario without breaking customers, please do add your thoughts!

[tlm]

Thank you for the update. We will keep maintaining our own enum.