x-ms-dynamic-values schema is dropped when moving from parameters to request body loading openapi for excel connector

[tomlm]

When loading this definition foo.txt

This path /drives/{drive}/files/{file}/tables/{table}/items/{id} The Patch operationId PatchItem somehow loses the reference to the x-ms-dynamic-schema attribute. The V2 json has Operation.Parameters entry like this:

 {
            "name": "item",
            "in": "body",
            "description": "Provide the item properties.",
            "required": true,
            "schema": {
              "$ref": "#/definitions/Item"
            },
            "x-ms-summary": "Provide the item properties"
          },

With the /definitions/Item looking like this:

"Item": {
      "description": "Table item entity",
      "type": "object",
      "properties": {
        "dynamicProperties": {
          "type": "object",
          "additionalProperties": {
            "$ref": "#/definitions/Object"
          }
        }
      },
      "additionalProperties": {
        "$ref": "#/definitions/Object"
      },
      "x-ms-dynamic-schema": {
        "operationId": "GetTable",
         ...
      }
    },

But the deserialized OpenApiOperation doesn't have any links or references to the x-ms-dynamic-schema data.

1. The Parameters doesn't have the "item" property defined (presumbly because it is moved to the RequestBody
2. The RequestBody has a definition with x-bodyName "item" but has dropped the "x-ms-dynamic-schema" metadata
3. The RequestBody.Content is empty

[tomlm]

Another example: foo2.txt OperationIds:

• PostItem
• PatchItem

[darrelmiller]

From what I can see, the schema of the request body is getting lost. It seems to be lost on writing of both v3 and V2, so the issue is likely in reading.

          {
            "in": "body",
            "name": "item",
            "description": "Provide the item properties.",
            "required": true,
            "schema": { },
            "x-ms-summary": "Provide the item properties"
          }

[darrelmiller]

~~The OpenAPIReferenceResolver visitor~~ https://github.com/microsoft/OpenAPI.NET/blob/vnext/src/Microsoft.OpenApi/Services/OpenApiReferenceResolver.cs ~~is not visiting Schemas in request bodies so the~~ $ref ~~is not getting resolved. On the surface this looks like an easy fix.~~

Well, that's not it. Back to the drawing board.

[darrelmiller]

@tomlm That one was a little harder to find than I expected. Here's the snippet of OpenAPI that is relevant.

    "/drives/{drive}/files/{file}/tables/{table}/items/{id}": {
      "patch": {
        "tags": [
          "ExcelOnlineTableData"
        ],
        "summary": "Update a row",
        "description": "Update a row using a key column. The input value will overwrite the specified cells and columns left blank will not be updated. In order to append (instead of overwrite) a value, use the \"Get a row\" action to retrieve the content first.",
        "operationId": "PatchItem",
        "consumes": [],
        "produces": [
          "application/json",
          "text/json",
          "application/xml",
          "text/xml"
        ],
        "parameters": [

This operation definition has an empty consumes array which infers the operation doesn't accept any request bodies. Obviously the parameter with "in" body contradicts that. We could use the presence of the body parameter to override, but we would really have to assume the default content type of application/octet-stream. You can correct the source document by adding the application/json entry to the consumes and then the content property will be set and the reference to the Item schema will be included in the model.

Just a heads up that if you are interacting with models read by the reader, we are going to have some breaking changes coming in our next major version. OpenAPIv3.1 allows some properties to live alongside $ref properties and this is causing us to have to redesign how we resolve references.

[darrelmiller]

Perhaps we should report an error if consumes is empty but there is a body parameter. This is very much a v2 problem because structurally you can't make this error in v3.