This section details on the original issue you should resolve

<issue_title>additionalProperties not set in schema for OpenApi V2 documents since v2.3.11, loss of information in things that return dictionaries</issue_title>
<issue_description>Describe the bug

We have some C# code with a schema that returns an IDictionary, where the value is a C# object, e.g.

public class TestItemResult
{
    public bool IsMatched { get; set; }
    public string? Reason { get; set; }
}


[HttpGet("test-items")]
public async Task<IDictionary<string, TestItemResult>> TestItem(...)
{
    // returns a dictionary of test item name to test result
}

Our OpenApi generation is configured to set.

OpenApiVersion = OpenApiSpecVersion.OpenApi2_0;

We are using OpenApi indirectly via Swashbuckle.AspNetCore, we picked up the change transitively with an upgrade from Swashbuckle.AspNetCore version 10.1.0 to 10.1.2, which changes the referenced version of Microsoft.OpenApi from 2.3.9 to 2.4.2

Expected behavior

With OpenApi 2.3.9, the response looks like this

  '/test-items':
    get:
      summary: ...
      produces:
        - application/json
      responses:
        '200':
          description: ...
          schema:
            type: object
            additionalProperties:
              $ref: '#/definitions/TestItemResult'

When browsing using swagger UI, the model is

{
  < * >:	TestItemResult{
    IsMatched: boolean
    Reason: string
  }
}

And the example response is

{
  "additionalProp1": {
    "IsMatched": true,
    "Reason": "string"
  },
  "additionalProp2": {
    "IsMatched": true,
    "Reason": "string"
  },
  "additionalProp3": {
    "IsMatched": true,
    "Reason": "string"
  }
}

From our perspective these are all correct and expected.

Actual behavior

Since OpenApi 2.3.11, the response looks like this (note additionalProperties missing)

  '/test-items':
    get:
      summary: ...
      produces:
        - application/json
      responses:
        '200':
          description: ...
          schema:
            type: object

When browsing using swagger UI, the model is

{
}

And the example response is

{}

Additional context

I looked at the OpenApi release history / changelog, and noted that the change starts with Issue 2619, wherein a user observes "Additional properties false" is incorrectly added to every object in shcema when switching to OpenAPI 3.1

It was then marked fixed in

• PR 2630 - fix: additional properties serialization should not emit a schema in v2 fix: additional properties serialization should not emit booleans in v3.1+
• PR 2631 - fix/additional properties to v3

Looking at the discussion in the issue and PR's, it looks as though the fix was intended to prevent spurious additionalProperties: false in v3.

It has also removed information from a v2 schema, which doesn't seem to fit with the intent of the bug fix.

If we pick up the new version, our customers will experience this as loss of information/functionality in the swagger document.

Was this loss of information intentional, and if so would it be possible to help us understand why, and/or if there are any changes we can make our our end to work around the issue?

Thank you

</issue_description>

<agent_instructions>follow instructions provided in copilot instructions and contributing.
Look at my reply for the fix that needs to be implemented.
Start by updating unit tests first, then fix the implementation.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Yes, the additionalProperties keyword should be serialized the same way across all versions since it's present since OpenAPI v2.0 and defined as a schema or boolean since JSON schema draft 04:

• When the boolean property is set to false, serialize false
• When the schema property is set to a schema, serialize the schema
• Otherwise, ignore the property

As for deserialization:

• If the value is set to false, deserialize that for the boolean property.
• If the value is an object, attempt deserializing a schema for the schema property.
• Otherwise do nothing, the default value should be true for the boolean property.

Is this something you'd like to submit a pull request for provided some guidance?

Related #2727 #2716</comment_new>