armresourcehealth v1.4.0 fails to unmarhsal armresourcehealth.Events due to type mismatch

[nimdanitro]

Bug Report

• import path of package in question: github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/resourcehealth/armresourcehealth

• SDK version: v1.4.0

• output of go version: go1.26.5

• What happened?
  We are consistently observing this unmarshalling error since upgrading from v1.3.0 to v1.4.0

unmarshalling type *armresourcehealth.Events: unmarshalling type *armresourcehealth.Events: struct field Value: unmarshalling type *armresourcehealth.Event: struct field Properties: unmarshalling type *armresourcehealth.EventProperties: struct field NewRate: json: cannot unmarshal string into Go value of type float64

Downgrading to v1.3.0 fixes the issue.

• What did you expect or want to happen?
  Events are properly unmarshalled as before

• How can we reproduce it?

package main

import (
	"context"
	"log/slog"
	"time"

	"github.com/Azure/azure-sdk-for-go/sdk/azcore/to"
	"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
	"github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/resourcehealth/armresourcehealth"
)

func main() {
	subscriptionID := "..." // FIXME: replace with subscription ID
	ctx := context.Background()
	defaultCreds, err := azidentity.NewDefaultAzureCredential(&azidentity.DefaultAzureCredentialOptions{})
	if err != nil {
		slog.Error("failed to create defaultCreds", "error", err)
	}
	client, err := armresourcehealth.NewClientFactory(subscriptionID, defaultCreds, nil)
	if err != nil {
		slog.Error("failed to create armresourcehealth clientFactory", "error", err)
	}

	pager := client.NewEventsClient().NewListBySubscriptionIDPager(
		&armresourcehealth.EventsClientListBySubscriptionIDOptions{
			QueryStartTime: to.Ptr(time.Now().AddDate(0, 0, -30).Format("01/02/2006")),
		},
	)

	for pager.More() {
		_, err := pager.NextPage(ctx)
		if err != nil {
			slog.Error("failed to page resourcehealth events: ", "error", err)
		}
	}
}
			

The above code works with v1.3.0 and fails with v1.4.0 of github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/resourcehealth/armresourcehealth

• Anything we should know about your environment.
  Nothing special.

[github-actions]

Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.

Generated by Agentic Triage for #27162 · 38.3 AIC · ⌖ 14.3 AIC · ⊞ 9.2K · ◷

[github-actions]

🎯 Agentic Issue Triage

Summary: The armresourcehealth v1.4.0 module introduced a breaking change where EventProperties.NewRate was changed to float64, but the Azure API returns a string value, causing JSON unmarshalling to fail. Downgrading to v1.3.0 resolves the issue.

📋 Issue Details

Module: github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/resourcehealth/armresourcehealth
Affected API: EventProperties.NewRate (field type mismatch)
Scenarios:

• Calling EventsClient.NewListBySubscriptionIDPager() in v1.4.0 fails with a JSON unmarshalling error when the API returns NewRate as a string instead of a number
• Downgrading to v1.3.0 works correctly, indicating a regression introduced in v1.4.0

Root ask: Fix the NewRate field type in EventProperties (should accept string values from the API, not float64) or provide a v1.4.1 patch release.

🔎 Debugging / Reproduction Notes

The error trace is:

unmarshalling type *armresourcehealth.Events: ... struct field NewRate: json: cannot unmarshal string into Go value of type float64

This suggests EventProperties.NewRate was typed as float64 in v1.4.0, but the Azure Resource Health service returns a JSON string for that field (not a number). This is a generated-code regression — the TypeSpec or REST API spec likely had a type change that is inconsistent with actual service behavior.

Suggested investigation steps:

1. Compare the EventProperties.NewRate field definition between v1.3.0 and v1.4.0 to confirm the type change.
2. Check the Azure REST API spec for resourcehealth to verify the intended type for newRate — if the spec says number but the service returns a string, it's a spec bug.
3. If the service returns a string, patch the generated code or open a fix in the upstream TypeSpec/REST spec, then cut a v1.4.1 release.

🏷️ Label Confidence

• Category: Mgmt — The module path sdk/resourcemanager/resourcehealth/armresourcehealth is explicitly under sdk/resourcemanager/, which maps to Mgmt.
• Service: Resource Health — The module armresourcehealth directly corresponds to the Azure Resource Health service; confirmed by # ServiceLabel: %Resource Health at CODEOWNERS line 555.
• Confidence: High — Module path unambiguously identifies both labels; no competing service or category candidates.

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Mgmt (line 649) — Bottom-to-top scan; this is the first entry whose labels (%Mgmt) are a subset of the issue's predicted labels {Mgmt, Resource Health}. No more-specific %Mgmt %Resource Health combined entry exists in the file.
• AzureSdkOwners: @lirenhe
• ServiceOwners: @lirenhe @tadelesh @JiaqiZhang-Dev``
• Routing action: Assigned @lirenhe (single AzureSdkOwner); added needs-team-attention label since issue is customer-reported.
• Scan notes: Line 555 (# ServiceLabel: %Resource Health) was encountered after line 649 during upward scan and was therefore skipped (first-match-wins). No entry combining both %Mgmt and %Resource Health was found.

Generated by Agentic Triage for #27162 · 38.3 AIC · ⌖ 14.3 AIC · ⊞ 9.2K · ◷

[tadelesh]

Hi @nimdanitro, thanks for the detailed report — we reproduced this end-to-end and confirmed the root cause.

Root cause: service/spec type mismatch

EventProperties.newRate / oldRate were added in v1.4.0. The TypeSpec definition declares them as float64:

/**
 * Billing rate change information - new rate
 */
newRate?: float64;

/**
 * Billing rate change information - old rate
 */
oldRate?: float64;

so the generated SDK types them as *float64. However, the service actually returns these fields as JSON strings. Capturing the raw response for a Billing-type event:

"properties": {
  "eventType": "Billing",
  ...
  "newRate": "0",
  "oldRate": "0"
}

Because the wire value is a string ("0") but the spec/SDK expect a numeric float64, unmarshalling fails. Running your exact repro (NewEventsClient().NewListBySubscriptionIDPager(...)) against a subscription that has a Billing event fails with the same error you reported:

unmarshalling type *armresourcehealth.Events: ... struct field OldRate:
json: cannot unmarshal string into Go value of type float64

v1.3.0 works only because it did not have these fields yet, so it silently ignored them.

Why we can't just patch the SDK

The Azure SDK for Go management-plane packages are generated from the official API specification (azure-rest-api-specs, authored in TypeSpec). We don't hand-edit the generated models, because the next regeneration would revert the change and it would drift from the contract the service publishes. The correct fix is to make the spec match the real service behavior (i.e. type newRate/oldRate as string, and fix the numeric examples), after which we regenerate and ship a patched SDK.

Next step (needs the service team)

Could you please open a support ticket with the Azure Resource Health / Service Health service team to fix this contract mismatch? The ask is:

Microsoft.ResourceHealth events API returns EventProperties.newRate / oldRate as JSON strings, but the TypeSpec declares them as float64. Please update the spec to reflect the actual service behavior (string), so downstream SDKs can be regenerated correctly.

Once the spec is corrected, we'll regenerate and release a fixed armresourcehealth. In the meantime, v1.3.0 is a viable workaround if you don't need these two new fields.

Thanks!