-
Notifications
You must be signed in to change notification settings - Fork 263
Closed
Labels
invalid-inputstatus:waiting-for-author-feedbackIssue that we've responded but needs author feedback to closeIssue that we've responded but needs author feedback to close
Milestone
Description
Describe the bug
When parsing an OpenAPI spec which contains a schema for the additionalProperties
field, the schema does not end up in the parsed OpenApiDocument
.
To Reproduce
Steps to reproduce the current behavior:
consider the following minimal spec (example.yml
):
openapi: 3.0.0
info:
title: Sample API
version: 0.1.9
paths:
/users:
get:
responses:
"200":
content:
application/json:
schema:
type: object
additionalProperties:
schema:
type: object
properties:
data:
type: string
And the code:
using Microsoft.OpenApi.Models;
using Microsoft.OpenApi.Readers;
var document = new OpenApiStreamReader().Read(File.OpenRead("example.yml"), out var diagnostics);
var additionalProperties = document.Paths["/users"].Operations[OperationType.Get].Responses[
"200"
].Content["application/json"]
.Schema
.AdditionalProperties;
Console.WriteLine(value: additionalProperties.Properties.Count); // prints "0"
This makes it impossible, to generate code based on the type of the additional properties (cf. #microsoft/kiota/62 )
Expected behavior
I would expect the additionalProperties
schema to be parsed and contain the schema of type "object"
with the properties dictionary containing a field data
of type string
.
Additional context
I think the parsing is in principle implemented in OpenApiSchemaDeserializer.cs#L161. However, somewhere there must be a bug.
Metadata
Metadata
Assignees
Labels
invalid-inputstatus:waiting-for-author-feedbackIssue that we've responded but needs author feedback to closeIssue that we've responded but needs author feedback to close