Skip to content

fix: response-key casing for EC2/NetworkManager reads + duplicate DescribeConnections call - #2

Open
agudmund wants to merge 1 commit into
aws-samples:mainfrom
agudmund:fix/response-key-casing
Open

fix: response-key casing for EC2/NetworkManager reads + duplicate DescribeConnections call#2
agudmund wants to merge 1 commit into
aws-samples:mainfrom
agudmund:fix/response-key-casing

Conversation

@agudmund

Copy link
Copy Markdown

Fixes #1.

What this changes

All fixes are response-key casing corrections along the camelCase/PascalCase split between the AWS APIs (Direct Connect speaks camelCase; EC2 and Network Manager speak PascalCase). 15 lines changed, no behavior added.

get_vpn_details — reads the PascalCase VgwTelemetry fields (Status, OutsideIpAddress, StatusMessage, AcceptedRouteCount), plus State and Routes. Before this, every tunnel rendered as null/0 and tunnels_up was always 0, contradicting network_architecture_summary which already read Status correctly.

get_virtual_gateway_details — reads State, and VpcId inside VpcAttachments. The vpc_id fix is one additional instance of the same defect found while preparing this PR (not listed in #1): attached VPC ids previously came back null.

analyze_cloudwan_topology — reads PascalCase State for global networks, core networks, and peerings. The output key is also normalized from "State" to "state" to match every other tool in the file; flagging this explicitly since it is a (small) output-schema change — the previous value was always null, so nothing working can break.

get_dx_vif_details — reads camelCase amazonSideAsn (Direct Connect is the camelCase API; this one was inverted in the other direction).

Duplicate API calldescribe_connections().get("connections", dx.describe_connections()...) evaluated its fallback eagerly, making two DescribeConnections calls per invocation and discarding the second result (three sites). The fallback is dropped, matching what network_architecture_summary already does.

I chose direct key corrections over wiring in the existing _get_key() helper to keep the diff minimal and reviewable; happy to rework onto _get_key() if you'd prefer that direction.

Testing

  • python -m py_compile server.py passes.
  • Field names verified against the boto3/API documentation for DescribeVpnConnections, DescribeVpnGateways, DescribeGlobalNetworks, ListCoreNetworks, ListPeerings, and DescribeVirtualInterfaces.
  • I don't have DX/VPN/Cloud WAN resources deployed to run a live end-to-end check, so a maintainer smoke test against a real account would be a welcome double-check.

Licensing

I confirm this contribution is made under the terms of the MIT-0 license of this repository.

…p eager duplicate DescribeConnections call

- get_vpn_details: read PascalCase VgwTelemetry fields (Status,
  OutsideIpAddress, StatusMessage, AcceptedRouteCount), State, and
  Routes so tunnel status, static routes, and tunnels_up report real
  values instead of null/0
- get_virtual_gateway_details: read State and VpcAttachments VpcId
  (PascalCase) so VGW state and attached VPC ids are populated
- analyze_cloudwan_topology: read PascalCase State for global networks,
  core networks, and peerings; normalize the output key to lowercase
  "state" to match every other tool
- get_dx_vif_details: read camelCase amazonSideAsn (Direct Connect is
  the camelCase API)
- drop the eagerly-evaluated fallback in
  describe_connections().get("connections", <second call>) which made
  a duplicate API call on every invocation and discarded the result

Fixes aws-samples#1

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Response-key casing mismatches: get_vpn_details reports 0 tunnels UP; VGW/Cloud WAN states always null

1 participant