Schema object allOf requires type

[tstibbs]

If a schema object uses allOf and includes an inline schema definition, but that inline definition doesn't specify type, then the inline definition is ignored (in java generation at least).

Minimal example:

openapi: 3.0.3
servers:
  - url: 'https://example.com'
info:
  title: example
  version: 0.0.1
paths:
  /path:
    post:
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/outerPayload'
      responses:
        '201':
          description: Created
          content:
            application/json:
              schema:
                type: string

components:
  schemas:
    outerPayload:
      allOf:
        - $ref: '#/components/schemas/innerPayload'
        - properties:
            someField:
              type: string
    innerPayload:
      properties:
        anotherField:
          type: string

Steps to reproduce

Run command: kiota generate --language java -n 'test'
Version: 1.10.1 (docker container mcr.microsoft.com/openapi/kiota)

Expected behaviour

A class test.OuterPayload should be generated with fields someField and anotherField and matching setter methods (note anotherField is in a superclass).

Actual behaviour

Only anotherField appears; someField is not generated.
No errors or warnings are logged - the fields/methods are simply missing in the generated java code.

Workaround

In the inline schema definition, include type: object.
Of course this is only possible if you are in control of the schema in use - so in most cases this workaround won't work.

Notes

I believe the above document is valid according to the OpenAPI spec. In all other situations, the type appears to default to object and it does not need to be specified explicitly. For example, in innerPayload in the example above, type: object is not required. It appears only to be within allOf that type: object is required.

[baywet]

Thanks for using kiota and for reaching out.
There are a couple of ways we could alleviate this.

We could add a validation rule that warns when a schema has properties, but its type isn't object. like this one

This would prompt people to edit their description and add the missing type object.

We could alliteratively/also change this evaluation rule to add am or condition branch which checks on the presence of properties. This might have side effects though. Additional unit tests would go here

Is this something you'd be interested in submitting a pull request for?

[baywet]

Hi @tstibbs
Here is a short update, I was able to isolate and fix the root cause of this issue in #4381
I'm still running tests for the other issues this PR is addressing, but it's promising!
Thanks for your patience on this.