Associate TGW Route Table step encounters 'NoneType' object has no attribute 'get'

[ckamps]

Describe the bug

The following exception occurred in the Associate TGW Route Table step of one of three state machine executions after three subnets were created and to which the Attach-to-tgw tag was added. Since the other two executions for two of the three subnets were successful, the TGW attachment was successfully associated with the TGW route table of interest.

[ERROR] AttributeError: 'NoneType' object has no attribute 'get'
Traceback (most recent call last):
  File "/var/task/tgw_vpc_attachment/main.py", line 72, in lambda_handler
    raise error
  File "/var/task/tgw_vpc_attachment/main.py", line 43, in lambda_handler
    return transit_gateway(event, function_name)
  File "/var/task/tgw_vpc_attachment/main.py", line 88, in transit_gateway
    response = tgw.associate_transit_gateway_route_table()
  File "/var/task/tgw_vpc_attachment/lib/exceptions.py", line 38, in wrapper_func
    response = func(self, *args, **kwargs)
  File "/var/task/tgw_vpc_attachment/lib/handlers/tgw_vpc_attachment_handler.py", line 554, in associate_transit_gateway_route_table
    response.get("Association").get("State"),

The code appears to be in def associate_transit_gateway_route_table(self):

...
            response = self.hub_ec2_client.associate_transit_gateway_route_table(
                association_route_table_id,
                transit_gateway_attachment_id,
            )
            state = self._get_association_state(
                association_route_table_id,
                response.get("Association").get("State"),
            )
...

Perhaps inspection of the response object should be performed before attempting to get the association state.

To Reproduce

Unclear since the behavior is inconsistent.

Expected behavior

The code should not assume that the EC2 API call is always successful.

Please complete the following information about the solution:

• [v3.3.6 ] Version: [e.g. v1.0.0]

To get the version of the solution, you can look at the description of the created CloudFormation stack. For example, "(SO0058) - The AWS CloudFormation template. Version v1.0.0".

• [ us-east-1]] Region: [e.g. us-east-1]
• [No ] Was the solution modified from the version published on this repository?
• [ NA] If the answer to the previous question was yes, are the changes available on GitHub?
• [ No] Have you checked your service quotas for the sevices this solution uses?
• [ Yes] Were there any errors in the CloudWatch Logs? How to enable debug mode?

Screenshots If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context Add any other context about the problem here.

[gsingh04]

We are testing fix in our environment currently. This will be pushed in upcoming release.

[ckamps]

Note that #116 and this issue refer to different sections of code. #116 focuses on propagation whereas this issue is focused on association. It's not clear to me how a fix for #116 relates to the issue described above.

[gsingh04]

Apologies for the confusion.

Both fixes are currently being tested in our environment. We plan to address them in upcoming release.

[gsingh04]

@ckamps would it be possible for you to try out the changes in the referenced PR in your environment and confirm if it resolves the issue for you.