SignalR Service API returns additional type `Trace` but it doesn't include in type list

[neil-yechenwei]

After checked, seems SignalR Service API returns additional type Trace in the response but it isn't involved in signalr request type list. Maybe service team have to make a fix to add this additional type Trace in rest api spec.

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

Issue Details

---

After checked, seems SignalR Service API returns additional type Trace in the response but it isn't involved in signalr request type list. Maybe service team have to make a fix to add this additional type Trace in rest api spec.

Author:	neil-yechenwei
Assignees:	akning-ms
Labels:	Service Attention, SignalR, needs-triage
Milestone:	-

[juniwang]

2020-05-01 is a very old version. The new type is included in newer api versions: https://github.com/Azure/azure-rest-api-specs/blob/master/specification/signalr/resource-manager/Microsoft.SignalRService/preview/2021-06-01-preview/signalr.json#L1960.

A new stable version is planning to be ready in Sept/Oct which will contain all new properties/APIs

[tombuildsstuff]

@juniwang 2020-05-01 is just over a year old, so it's not old relative to other API specs (2015) in this repository - if the API spec is in this repository it should contain all of the supported values in the API.

Is there a timeframe for when this value will get added to this API?

[juniwang]

Adding new enum values is considered as breaking change which requires new api-version anyway. So, we don't have a plan to update 2020-05-01. Trace is incorrectly returned by accident. A new stable api-version is on the way with correct values.

[tombuildsstuff]

@juniwang adding new enum values is not a breaking change (particularly when the API accepts those values anyway) - changing (for example the casing of) or removing enum values is a breaking change, however

cc @JeffreyRichter to confirm that?

[JeffreyRichter]

Adding a new enum value to an enum that is modeled as string is OK (because it is just a new string value); adding a new enum value that to an enum that is not modeled as string is NOT OK (because returning it to an old client will cause the deserializer to throw an exception).