We are seeing this in production on two subscriptions in a customer tenant. Azure returns response bodies of the shape:
unmarshalling type *armhybridcompute.MachineListResult:
struct field Value:
unmarshalling type *armhybridcompute.Machine:
struct field Properties:
unmarshalling type *armhybridcompute.MachineProperties:
struct field ErrorDetails:
unmarshalling type *armhybridcompute.ErrorDetail:
json: cannot unmarshal string into Go value of type map[string]json.RawMessage
Import path of package in question:
github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/hybridcompute/armhybridcomputev1.2.0— also reproduces inv2.0.0(latest stable) andv2.1.0-beta.3(theErrorDetail.UnmarshalJSONbody is byte-for-byte identical across all three).go version go1.22 darwin/arm64(also reproduces on linux/amd64)armhybridcompute.MachinesClient.NewListBySubscriptionPager(...).NextPage(ctx)fails with an unmarshal error and returns zero machines whenever Azure returns any element ofproperties.errorDetailsas a plain JSON stringinstead of an
ErrorDetailobject. One bad element in one machine aborts the entire page, so callers lose every machine in the response — not just the offending one.We are seeing this in production on two subscriptions in a customer tenant. Azure returns response bodies of the shape:
{ "value": [ { "id": "/subscriptions/.../providers/Microsoft.HybridCompute/machines/<name>", "properties": { "status": "Disconnected", "errorDetails": ["machine offline"] // <-- string, not object } } ] }The pager should either:
ErrorDetail{Message: &s}), orso that a single malformed
errorDetailselement does not nullify the entire list response.pager.NextPage(ctx)returns:ErrorDetail.UnmarshalJSONinsdk/resourcemanager/hybridcompute/armhybridcompute/models_serde.go(lines 212–242 inv1.2.0) hard-requires a JSON object on the very first call: