GET request to list VMs doesn't need a body

[vsotog]

The requests sent here: https://github.com/Azure/azure-sdk-for-rust/blob/b13b3b5b02610f2de2086ff809ec1f691c0bd900/services/mgmt/compute/src/package_2022_11_01/mod.rs#L2562-L2563

And here: https://github.com/Azure/azure-sdk-for-rust/blob/main/services/mgmt/compute/src/package_2022_11_01/mod.rs#L2580-L2581

are GET HTTP requests, but include a body, azure_core::EMPTY_BODY is an empty string, but not an empty body.

[cataggar]

That is a byte string literal. https://doc.rust-lang.org/reference/tokens.html#byte-string-literals

[cataggar]

More details here: https://docs.rs/bytes/latest/bytes/struct.Bytes.html#method.new

https://github.com/Azure/azure-sdk-for-rust/blob/6685f319f238d254c9d974b40dc2a6760a157cf8/sdk/core/src/lib.rs#L77-L79C1

You can see the actual http request using an http proxy like Fiddler 4 and setting an environment variable to use it.

$env:HTTPS_PROXY="http://localhost:8888"

[vsotog]

That makes sense, thanks. The issue may be some place else.

Any ideas on why I get this error when doing virtual_machine_scale_set_v_ms_client() .list(resource_group, vmss_name, subscription_id) .into_stream();?

Err(Error { context: Custom(Custom { kind: DataConversion, error: Error("invalid type: null, expected a string", line: 10, column: 12) }) })

From the logs, it looks like it's just doing a GET /subscriptions/my-subscription/resourceGroups/my-resource-group/providers/Microsoft.Compute/virtualMachineScaleSets/my-vmss/virtualMachines and the request works when using something else like Postman or curl.

The error suggests: "response body was not utf-8 like expected"

[dpiche174]

Here is the raw output returned by the API /subscriptions/{subscription-id}/resourceGroups/{resource-group-id}/providers/Microsoft.Compute/virtualMachineScaleSets/{scale-set-id}/virtualMachines

{
  "value": [
    {
      "name": "some-vm-123",
      "id": "/subscriptions/b68cbdae-dc1d-4624-be14-9f7ca168a9e3/resourceGroups/my-resource-group/providers/Microsoft.Compute/virtualMachineScaleSets/my-vmss/virtualMachines/some-vm-123",
      "type": "Microsoft.Compute/virtualMachineScaleSets/virtualMachines",
      "location": "eastus",
      "instanceId": "some-vm-123",
      "zones": [null]
    },
    {
      "name": "some-vm-456",
      "id": "/subscriptions/b68cbdae-dc1d-4624-be14-9f7ca168a9e3/resourceGroups/my-resource-group/providers/Microsoft.Compute/virtualMachineScaleSets/my-vmss/virtualMachines/some-vm-456",
      "type": "Microsoft.Compute/virtualMachineScaleSets/virtualMachines",
      "location": "eastus",
      "instanceId": "some-vm-456",
      "zones": [null]
    }
  ]
}

It seems that the struct VirtualMachineScaleSetVm is not able to handle "zones": [null].

If availability zones are set on the VMSS, VirtualMachineScaleSetVm can deserialize the body with no problem.

[cataggar]

@dpiche174, thanks for the raw response. That is definitely an invalid response from the compute service for the operation VirtualMachineScaleSetVMs_Get. The spec is defined as VirtualMachineScaleSetVM at https://github.com/Azure/azure-rest-api-specs/blob/529205bb71049de32c1126c69b6016904261da32/specification/compute/resource-manager/Microsoft.Compute/ComputeRP/stable/2022-11-01/virtualMachineScaleSet.json#L5479-L5486 with:

        "zones": {
          "readOnly": true,
          "type": "array",
          "items": {
            "type": "string"
          },
          "description": "The virtual machine zones."
        },

To allow null, they would need to add:

        "zones": {
          "readOnly": true,
          "type": "array",
          "items": {
            "type": "string",
            "x-nullable": true
          },
          "description": "The virtual machine zones."
        },

But x-nullable is discouraged and the service should not be setting it.

Although this SDK does not have official support, the service MUST adhere to its API specification. It is not. Please file a support request with Azure Support.

[cataggar]

A workaround would be to comment out zones from that model if you do not need that info in a fork. Not great, but would unblock you.