HTML rendering broken / unusable when allOf and oneOf even if spec is considered 0 warning

[LasneF]

Describe the bug

given a specification with no error , no warning using redocly lint , the documentation generated via redocly build-docs "crashes" at rendering , and make it unusable

To Reproduce
given the Open API description attached

run redocly build-docs .\component-descriptor.yml

Open the HTML File produce ,

select for kind the value CAT , the HTML rendering is ok
select for kind the value DOG ; the HTML rendering is broken and does not allow anymore to choose a value

Expected behavior

Either the API specification is considered as invalid are not renderable , and the build doc should shoot an error ,can be at the build doc or at the linter level

Either it is considered as correct and the rendering should be OK

Logs
NA

OpenAPI description
cf attached file (notice that yml or json does not matter)

Redocly Version(s)
redocly --version
1.16.0

Node.js Version(s)
node --version
v18.16.0

Additional context

component-descriptor.json

[LasneF]

notice that according to https://github.com/hyperjump-io/json-schema.hyperjump.io and
https://github.com/gregsdennis/json-everything the schema describe is "valid" , and is working as expected.

[tatomyr]

If you remove the oneOf inside Dog, it starts working. On one hand, it's redundant, and removing it even makes the documentation a bit more readable. On the other hand, the schema is valid, so I'd expect Redoc to render it correctly.

@Redocly/keyboard-warriors, could you check if it's a bug on Redoc's end?

[LasneF]

@tatomyr you are right , the sample has been over simplified , as the real use case was to have
AllOf ( something + oneOf ( A or B) + oneOf(C+D) )

[AlexVarchuk]

It is Redoc issue. We'll look into it later.

[NigelThorne]

I think I've hit this issue too.
I have two files (firstChoice.json and secondChoice.json) of the structure

{"oneOf": [{ ...},{...}]}

and a schema file (both.json) that references them both

{ "allOf": [{"$ref": "firstChoice.json"}, {"$ref": "secondChoice.json"}]

Using the CLI to generate the docs, using both.json as an endpoints schema, the documentation only shows the second choice fields.

so switching the order causes the other choice to be visible.

{ "allOf": [{"$ref": "secondChoice.json"}, {"$ref": "firstChoice.json"}]

However... If I inline the refs, I can get it to show both fields.

{ "allOf": [{"oneOf": [{ ...},{...}]}, {"oneOf": [{ ...},{...}]}]

If one of the refs is not an 'oneOf' that also seem to work fine for me.

{ "allOf": [{"$ref": "firstChoice.json"}, {"$ref": "notAChoice.json"}]

[jeremyfiel]

@NigelThorne

If I understand your issue, this should be a valid reproduction of it...

openapi: 3.0.3
info:
  title: '2562'
  version: '0.0.1'
servers:
  - url: https://redocly.com
paths:
  '/thing':
    get:
      summary: test allOf with nested oneOf by $ref
      responses:
        '200':
          description: OK
          content:
            'application/json':
              schema:
                allOf:
                  - $ref: '#/components/schemas/one-of-1'
                  - $ref: '#/components/schemas/one-of-2'
              examples:
                one-of-1:
                  value: 
                    that: 'test'
                one-of-2:
                  value:
                    thing: 'test'
                all-of:
                  value:  
                    thing: 'test'
                    that: "doesn't work"
components:
  schemas:
    one-of-1:
      title: one-of-1
      type: object
      oneOf:
        - properties:
            this:
              type: string
        - properties:
            that:
              type: string
    one-of-2:
      title: one-of-2
      type: object
      oneOf:
        - properties:
            thing:
              type: string
        - properties:
            another_thing:
              type: string

# redocly.yaml
extends:
  - recommended
rules:
  no-invalid-media-type-examples: warn

---

In this case, the schema defined is illogical because you can never have a valid instance against this schema.

The allOf looks at both individual schemas, and within each of them is a oneOf definition, which means the data instance can ONLY be one of those oneOf schemas, thus allOf fails because not ALL OF the schemas pass validation.

take these examples to explain further:

individual property from one-of-1 fails

{
  "that": "test"
}

individual property from one-of-2 fails

{
  "thing": "test"
}

trying one property from each subschema still fails

{
  "thing": "test",
  "that": "doesn't work"
}

---

I don't think Redocly look the schemas with any schema logic considered, so they should still render this illogical schema but, this is not a valid schema if you were to use it for validation and you should be able to see redocly linting does the job correctly and reports the errors.