public_ip_address method within NetworkManagementClient will not return values

[Mordecaine]

• Package Name: azure-mgmt-network
• Package Version: 28.1.0
• Operating System: RedHat Enterprise Linux 9.5
• Python Version: 3.12.5

Describe the bug
See Issue #10735 this is exactly the same error that I have. So I copy the issue description and the way to reproduce the issue (hope that is ok for @khantext) :

When a public IP address actually does exist, the public_ip_address method nevertheless always returns a <class 'azure.mgmt.network.v2018_12_01.models.public_ip_address_py3.PublicIPAddress'> object with all empty (None) values. For example...

{'additional_properties': {}, 'id': '/subscriptions/xxxxxxxxx/resourceGroups/lbi-azure-web-proxy-rg/providers/Microsoft.Network/publicIPAddresses/lbiazpwproxy001664', 'name': None, 'type': None, 'location': None, 'tags': None, 'sku': None, 'public_ip_allocation_method': None, 'public_ip_address_version': None, 'ip_configuration': None, 'dns_settings': None, 'ddos_settings': None, 'ip_tags': None, 'ip_address': None, 'public_ip_prefix': None, 'idle_timeout_in_minutes': None, 'resource_guid': None, 'provisioning_state': None, 'etag': None, 'zones': None}

To Reproduce
Steps to reproduce the behavior:

Import the NetworkManagementClient << from azure.mgmt.network import NetworkManagementClient >>
Establish 'credentials' and 'subscription_id' variables.
Create a network client << network_client = NetworkManagementClient(credentials, subscription_id) >>
Query a network interface known to have a Public IP address << response = network_client.network_interfaces.get("lbi-azure-web-proxy-rg", "lbiazpwproxy001664").ip_configurations[0].public_ip_address >>
Print the response << print(response) >>
You should see the results with all 'None' values populated.

Expected behavior
I expect for the actual values to be returned. As a test, I ran what should be the same query using the Python 'requests' module against this URL: "https://management.azure.com/subscriptions/xxxxxxxxxx/resourceGroups/lbi-azure-web-proxy-rg/providers/Microsoft.Network/publicIPAddresses/lbiazpwproxy001664?api-version=2019-07-01", and it returned valid results (see below). I used the same credentials against the same subscription.

Result using Python 'requests' against URL:

{
"name": "lbiazpwproxy001-ip",
"id": "/subscriptions/xxxxxxxxxx/resourceGroups/lbi-azure-web-proxy-rg/providers/Microsoft.Network/publicIPAddresses/lbiazpwproxy001-ip",
"etag": "W/"f151da9d-940f-4b7c-8caa-73a94342234d"",
"location": "eastus2",
"tags": {
"Cost Cent": "xxxx",
"Cost Center": "xxxxx"
},
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "4a41ceba-989e-488b-9d57-xxxxxxxxxxxx",
"ipAddress": "40.79.xxx.xxx",
"publicIPAddressVersion": "IPv4",
"publicIPAllocationMethod": "Dynamic",
"idleTimeoutInMinutes": 4,
"ipTags": [],
"ipConfiguration": {
"id": "/subscriptions/xxxxxxxxxx/resourceGroups/lbi-azure-web-proxy-rg/providers/Microsoft.Network/networkInterfaces/lbiazpwproxy001664/ipConfigurations/ipconfig1"
}
},
"type": "Microsoft.Network/publicIPAddresses",
"sku": {
"name": "Basic"
}
}

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @vnetsuppgithub.

[github-actions]

Hello @Mordecaine. I'm an AI assistant for the azure-sdk-for-python repository. I have some suggestions that you can try out while the team gets back to you.

• This issue appears to replicate the behavior described in #10735. The public IP address object is populated with None values, even though a valid address exists.

• The reproduction steps and the JSON response using the Python requests module reinforce that the underlying API returns valid data. It might be helpful to compare the API version used in the SDK (in your case, version 28.1.0) with the one used in your manual call (e.g., api-version=2019-07-01).

• As a workaround, consider using direct REST API calls or evaluating if a different API version in the SDK returns the expected values.

• Please reference the detailed discussion and reproduction steps in #10735 for further context.

The team will get back to you shortly, hopefully this helps in the meantime.