When an OpenAPI 3 schema uses oneOf with multiple array-of-string schemas that differ only by enum, the rendered output collapses to a generic:
oneOf: array[string]
This loses important semantic detail for API consumers, even though the OpenAPI definition is valid.
Example
"adminrights": {"oneOf": [{"type": "array","minItems": 1,"maxItems": 1,"items": {"type": "string","enum": ["full"]}},{"type": "array","items": {"type": "string","enum": ["user","app"]}}]},
Output
Expected
The renderer should preserve or expose the distinct oneOf branches (or their enum constraints), instead of flattening them into a generic array type.
Notes
This appears to be a rendering/modeling fallback triggered when oneOf has multiple non-$ref children of identical shape.
When an OpenAPI 3 schema uses oneOf with multiple array-of-string schemas that differ only by enum, the rendered output collapses to a generic:
oneOf: array[string]
This loses important semantic detail for API consumers, even though the OpenAPI definition is valid.
Example
"adminrights": {"oneOf": [{"type": "array","minItems": 1,"maxItems": 1,"items": {"type": "string","enum": ["full"]}},{"type": "array","items": {"type": "string","enum": ["user","app"]}}]},
Output
Expected
The renderer should preserve or expose the distinct oneOf branches (or their enum constraints), instead of flattening them into a generic array type.
Notes
This appears to be a rendering/modeling fallback triggered when oneOf has multiple non-$ref children of identical shape.