AccepterTransitGatewayAttachmentId missing from ec2.describe_transit_gateway_peering_attachments response

jamesinc commented 1 year ago

Describe the bug

There has been some recent change to the API behaviour for Transit Gateway peering attachments. In the past, both the source and consumer peering attachment IDs were identical. However, now it seems each account receives a unique ID both corresponding to the same peering attachment.

The API calls for create_transit_gateway_peering_attachment and describe_transit_gateway_peering_attachments have also been updated to include a new key, AccepterTransitGatewayAttachmentId, however I am finding that this key is missing for calls to describe_transit_gateway_peering_attachments. In my scenario, the peering attachment is in a pendingAcceptance state.

Expected Behavior

Response payload contains the Accepter Transit Gateway Attachment ID as specified in the boto documentation here:

{
    'TransitGatewayPeeringAttachments': [
        {
            'TransitGatewayAttachmentId': 'string',
            'AccepterTransitGatewayAttachmentId': 'string',
            // ... snip ...

Current Behavior

The key is missing entirely from the response payload

Reproduction Steps

Create a transit gateway in account A in us-east-2, create another transit gateway in account B also in us-east-2, then (using Boto) create a peering attachment between those two transit gateways.

Possible Solution

Restore the missing key

Additional Information/Context

Without the AccepterTransitGatewayAttachmentId key, and with the requester and accepter now having different attachment IDs for the same peering attachment, it becomes much more difficult to unambiguously resolve attachments (I know it's possible, but this is a big change in behaviour and I am creating/managing peering attachments at scale).

create_transit_gateway_peering_attachment returns the AccepterTransitGatewayAttachmentId as expected.

SDK version used

1.28.25

Environment details (OS name and version, etc.)

Python 3.10, AWS Lambda/amzn2

RyanFitzSimmonsAK commented 1 year ago

Hi @jamesinc, thanks for reaching out. Could you provide debug logs of this behavior? You can get debug logs by adding boto3.set_stream_logger('') to the top of your script, and redacting any sensitive information. Thanks!

jamesinc commented 1 year ago

Hey @RyanFitzSimmonsAK, sorry it took a while to get these logs, this error is buried quite a long way from our dev environment so I had to jump some hoops to get direct access.

boto-tgw.log

RyanFitzSimmonsAK commented 1 year ago

Hi @jamesinc, thanks for your patience. I am still investigating this issue. Currently my thought is that this is a service team issue, so I've reached out to the appropriate team, and will update this issue when I know more.

RyanFitzSimmonsAK commented 1 year ago

Hi @jamesinc, thanks for your patience. This is intended behavior; AccepterTransitGatewayAttachmentId should only be present in the response to CreateTransitGatewayPeeringAttachment, and not DescribeTransitGatewayPeeringAttachments. The documentation includes all items that can appear in a response, but not all of them might necessarily do so. AccepterTransitGatewayAttachmentId can appear as part of a TransitGatewayPeeringAttachment, so it must be included in the docs, but won't be included in real responses for describe calls.

Hope that helps, and please let me know if you have any follow-up questions.

jamesinc commented 1 year ago

Thanks @RyanFitzSimmonsAK yeah the documentation is definitely confusing on this, but I can work around that limitation, thanks for investigating it.

boto / boto3