|
1 |
| -from docs.examples.openapi import customize_pydantic_model_name |
| 1 | +from docs.examples.openapi import customize_openapi_types, customize_pydantic_model_name |
2 | 2 |
|
3 | 3 | from litestar.testing import TestClient
|
4 | 4 |
|
@@ -44,3 +44,28 @@ def test_customize_path() -> None:
|
44 | 44 | with TestClient(app=app) as client:
|
45 | 45 | resp = client.get("/docs/openapi.json")
|
46 | 46 | assert resp.status_code == 200
|
| 47 | + |
| 48 | + |
| 49 | +def test_schema_types_sorted() -> None: |
| 50 | + """ |
| 51 | + Handles an edge case where types are not `oneOf`; instead a bare list of types considered as an enum. |
| 52 | +
|
| 53 | + The following is what the OpenAPI 3.0 spec provides as a consistent way of describing types. |
| 54 | + These types appear to be sorted consistently for other models. |
| 55 | +
|
| 56 | + `{'oneOf': [{'type': 'string', 'const': '1'}, {'type': 'null'}]}` |
| 57 | +
|
| 58 | + The following is what a `Literal | None` type is converted to in the spec. The type field is not sorted |
| 59 | + deterministically, which can result in CI failures due to changed spec generation. |
| 60 | +
|
| 61 | + `{'type': ['null', 'string'], 'enum': ['1', None]}` |
| 62 | +
|
| 63 | + Without this change, the 'type' key above may display `['string', 'null']` depending on the system. |
| 64 | + """ |
| 65 | + with TestClient(app=customize_openapi_types.app) as client: |
| 66 | + schema = client.app.openapi_schema.to_schema() |
| 67 | + |
| 68 | + nested_query_type = schema["paths"]["/"]["post"]["parameters"][0]["schema"]["type"] |
| 69 | + |
| 70 | + # Types should be sorted alphabetically. |
| 71 | + assert nested_query_type == ["null", "string"] |
0 commit comments