Update Generated Types

[github-actions]

Update Generated Types

Generate types for https://github.com/Azure/azure-rest-api-specs/tree/9722d269ce8ad6bf8de7e8083f0409e8bcb0569f

Summary

Failed to generate types for path 'adhybridhealthservice'

Exited with code 1

Failed to generate types for path 'securityinsights'

Exited with code 1

Failed to generate types for path 'service-map'

Exited with code 1

Failed to generate types for path 'timeseriesinsights'

Exited with code 1

Failed to generate types for path 'web'

Exited with code 1

[jeskew]

No properties were removed, but the ones marked as line deletions only exist on the PUT request and are now flagged as WriteOnly.

The particular resource that uses this synthetic object definition had the PUT and GET defined as distinct paths, one with a constant name and the other with a parameterized name.

[jeskew]

Same behavior as is demonstrated in 2015-08-01 version.

[jeskew]

The GET side of this resource allows any string to be used as the name parameter. We were previously only looking at the PUT side, which uses a closed enum.

[jeskew]

So, this resource is a bit weird. The GET side of the resource allows 'current' or 'recommended', which I assume correspond to "tell me what sensitivity labels are in use" and "tell me what sensitivity labels you think I should be using," respectively. The PUT side only allows 'current', because this is essentially a singleton child resource of Microsoft.Sql/servers/databases/schemas/tables/columns. The updates needed to support GET and PUT sides of the same resource defined at slightly differing paths requires the type generator to look at how a resource's name is defined on both GET and PUT and reconcile them, which has the interesting side effect we see here.

In an ideal world, I would probably want there to be a POST action on Microsoft.Sql/servers/databases/schemas/tables/columns called something like listRecommendedSensitivityLabels instead of having the provider overload the GET side of the resource like this. But I'm OK with the end result, even if it is a bit unexpected.

[jeskew]

Same issue as observed in sql path with Microsoft.Sql/servers/databases/schemas/tables/columns/sensitivityLabels resource.

[jeskew]

I'm not sure that this is wrong, but the name certainly looks weird. The RP method does follow the hierarchical resource naming pattern, and the response body is tagged by the service as a resource. My guess is that this is an error in the Swagger (i.e., there is a missing /providers/ path segment that should precede Microsoft.Consumption) that accidentally happened to qualify as a resource.

[jeskew]

This resource defines its PUT with a constant name (the path ends in /default) and uses a parameterized path for the GET method targeting the same resource type at the same scope. What's being generated here is not incorrect IME, but this is an interesting collateral effect.

[jeskew]

This is another case where the PUT side uses a constant string name and the GET side uses a parameterized name.

Looking at the semantics of the PUT method that's currently being captured as a resource, I believe this is an RP modeling error. The PUT method should be a POST action, and the /backups resource should be read only. That'd be a breaking change and would need to be fixed in the swagger.