[BUG] monitor insights type widening during TypeSpec conversion

[matthchr]

API Spec link

azure-rest-api-specs/specification/monitor/resource-manager/Microsoft.Insights/Insights/DataCollectionApi/models.tsp

Line 1805 in 8d52135

customVMScrapeConfig?: unknown[];

API Spec version

2024-03-11 (may also impact newer versions)

Describe the bug

When the Microsoft.Insights Swagger went through TypeSpec conversion, it seems to have (mistakenly?) produced a widening on one property.

Here's Microsoft.Insights sample before TypeSpec migration for the customVMScrapeConfig field.

        "customVMScrapeConfig": {
          "description": "Custom VM Scrape Config that defines scrape jobs",
          "type": "array",
          "items": {
            "type": "object"
          }
        },

In TypeSpec that was modelled as:

customVMScrapeConfig?: unknown[];

Which renders into OpenAPI as:

        "customVMScrapeConfig": {
          "type": "array",
          "description": "Custom VM Scrape Config that defines scrape jobs",
          "items": {}
        },

Which has a loosened set of restrictions on the array items (allows bool, int, etc, whereas before it had to be an object).

See OAI/OpenAPI-Specification#1388 for a discussion of why "type": "object" and "no type specified" do not mean the same thing.

I think the TypeSpec should have been Record<unknown>[] to preserve the old object restriction.

Expected behavior

        "customVMScrapeConfig": {
          "type": "array",
          "description": "Custom VM Scrape Config that defines scrape jobs",
          "items": {}
        },

items should be of type object.

Actual behavior

items is not of type object.

Reproduction Steps

Read the openAPI specification links above?

Environment

No response

[matthchr]

This also happened with Quota properties which used to have a type: object and now doesn't after TypeSpec conversion, so it may be a systemic issue with the auto-conversion tool?

cc @timotheeguerin who may know if that's likely/possible.

[timotheeguerin]

The reason for that change is that type: object was incorrectly treated as unknown in SDK with autorest despite what the openapi/swagger spec said so we kept the original meaning to not introduce breaking changes.

See Azure/typespec-azure#1725 (comment)