wing328
commented
10 months ago generateAliasAsModel: true
can you try setting it to false instead?
Open doctorpangloss opened 10 months ago
wing328
commented
10 months ago generateAliasAsModel: true
can you try setting it to false instead?
doctorpangloss
commented
9 months ago This causes other errors:
....
[main] INFO o.o.codegen.DefaultGenerator - Model Prompt not generated since it's a free-form object
[main] INFO o.o.codegen.DefaultGenerator - Model Outputs not generated since it's a free-form object
[main] INFO o.o.codegen.DefaultGenerator - Model upload_image_request not generated since it's marked as unused (due to form parameters) and `skipFormModel` (global property) set to true (default)
[main] WARN o.o.c.l.AbstractPythonCodegen - Failed to lookup model in createImportMapOfSet Dict[str, PromptNode]
[main] WARN o.o.c.l.AbstractPythonCodegen - Failed to lookup model in createImportMapOfSet Dict[str, Output]
[main] WARN o.o.c.l.AbstractPythonCodegen - Failed to lookup model in createImportMapOfSet Dict[str, PromptNode]
[main] WARN o.o.c.l.AbstractPythonCodegen - Codegen property is null (e.g. map/dict of undefined type). Default to typing.Any.
[main] WARN o.o.c.l.AbstractPythonCodegen - Codegen property is null (e.g. map/dict of undefined type). Default to typing.Any.
[main] WARN o.o.c.l.AbstractPythonCodegen - Codegen property is null (e.g. map/dict of undefined type). Default to typing.Any.
...No... these are maps with typed values. This must be a bug. See the updated colab here: https://github.com/OpenAPITools/openapi-generator/issues/17755#issuecomment-1920919909
mharding-hpe
commented
1 week ago I am seeing this problem with version 7.10.0 with every schema of type array.
mharding-hpe
commented
1 week ago The following openapi file reproduces the bug:
openapi: "3.0.3"
info:
title: "Bug example"
version: "1.2.3"
description: Demonstrating issue 17755
components:
schemas:
StringList:
description: List of strings
type: array
items:
type: string
paths: {}I generate the code with the following:
podman run -v $(pwd):/harf docker.io/openapitools/openapi-generator-cli:v7.10.0 generate -i /harf/openapi.yaml -g python -o /harf/17755 --generate-alias-as-modelIt succeeds, but in the output, I do see the following:
[main] WARN o.o.codegen.utils.ModelUtils - Failed to get the schema name: nullAnd in the generated model code:
from pydantic import ConfigDict, RootModel
from typing import Any, ClassVar, Dict, List
from openapi_client.models.null<str> import null<str>
from typing import Optional, Set
from typing_extensions import Self
class StringList(null<str>):Further testing confirms that this bug does not exist in v6.6.0 but exists in v7.0.0 (and v7.0.0-beta)
mharding-hpe
commented
1 week ago In the last version where the bug did not exist, the corresponding lines of the Python model were:
import typing # noqa: F401
import typing_extensions # noqa: F401
import uuid # noqa: F401
import frozendict # noqa: F401
from openapi_client import schemas # noqa: F401
class StringList(
schemas.ListSchema
):I misspoke. I made the mistake of using the python generator when I was using v6.6.0. However, I was reviewing the release notes for v7.0.0-beta, and I noticed this:
Rename python-nextgen to python by @wing328 in https://github.com/OpenAPITools/openapi-generator/pull/15504
And when I use python-nextgen with v6.6.0, the bug still occurs.
So this only gives the appearance of being a regression between v6 and v7 -- in fact, this problem already existed in v6, but the renaming of the generators masked that fact.
mharding-hpe
commented
1 week ago Looking further back, I can see that the python-nextgen generator was added new in v6.3.0, and this bug exists there. So as best I can tell, this bug has always existed with this generator.
I was hoping to find out when this broke, so I could try and see if I could spot what caused it, but no such luck. I am not familiar with the source code for this tool, so further investigation will be slow going. But unless I am mistaken, all array models are broken with this generator.
mharding-hpe
commented
1 week ago In case it is helpful, I built openapi-generator locally, but uncommented these commented throw statements. This is the resulting stack trace when generating:
[main] WARN o.o.codegen.utils.ModelUtils - Failed to get the schema name: null
[main] ERROR o.o.codegen.DefaultGenerator - An exception occurred in OpenAPI Normalizer. Please report the issue via https://github.com/openapitools/openapi-generator/issues/new/:
[main] ERROR o.o.codegen.DefaultGenerator - An exception occurred in OpenAPI Normalizer. Please report the issue via https://github.com/openapitools/openapi-generator/issues/new/:
java.lang.RuntimeException: Failed to get the schema: null
at org.openapitools.codegen.utils.ModelUtils.getSimpleRef(ModelUtils.java:387)
at org.openapitools.codegen.OpenAPINormalizer.isSelfReference(OpenAPINormalizer.java:581)
at org.openapitools.codegen.OpenAPINormalizer.fixSelfReferenceSchema(OpenAPINormalizer.java:547)
at org.openapitools.codegen.OpenAPINormalizer.normalizeComponentsSchemas(OpenAPINormalizer.java:517)
at org.openapitools.codegen.OpenAPINormalizer.normalize(OpenAPINormalizer.java:299)
at org.openapitools.codegen.DefaultGenerator.configureGeneratorProperties(DefaultGenerator.java:275)
at org.openapitools.codegen.DefaultGenerator.generate(DefaultGenerator.java:1288)
at org.openapitools.codegen.cmd.Generate.execute(Generate.java:535)
at org.openapitools.codegen.cmd.OpenApiGeneratorCommand.run(OpenApiGeneratorCommand.java:32)
at org.openapitools.codegen.OpenAPIGenerator.main(OpenAPIGenerator.java:66)@mharding-hpe did you try the latest stable version v7.10.0 released a few days ago?
mharding-hpe
commented
1 week ago @wing328 yes, the bug exists there as well. It also exists in the latest master branch (as of yesterday, anyway).
mharding-hpe
commented
4 days ago This same bug happens with the python-fastapi and python-pydantic-v1 generators.
It does not happen with python-aiohttp, python-blueplanet, or python-flask.
(all of the above verified with v7.10.0, using the same test to reproduce as in my earlier comment)
mharding-hpe
commented
3 days ago In addition to the problems with the array model that I noted earlier, there are some other things that look wrong (although they are not syntax errors like the problem noted before). Namely, the model defines the to_dict and from_dict methods, which don't make sense for an array:
def to_dict(self) -> Dict[str, Any]:
"""Return the dictionary representation of the model using alias.
This has the following differences from calling pydantic's
`self.model_dump(by_alias=True)`:
* `None` is only added to the output dict for nullable fields that
were set at model initialization. Other fields with value `None`
are ignored.
"""
excluded_fields: Set[str] = set([
])
_dict = self.model_dump(
by_alias=True,
exclude=excluded_fields,
exclude_none=True,
)
return _dict
@classmethod
def from_dict(cls, obj: Optional[Dict[str, Any]]) -> Optional[Self]:
"""Create an instance of StringList from a dict"""
if obj is None:
return None
if not isinstance(obj, dict):
return cls.model_validate(obj)
_obj = cls.model_validate({
})
return _objI note that models for other primitive types (like enumerated strings) don't have those methods. So I suspect the fact that they are present here is further indication that the code which generates models has some kind of blind spot in terms of handling arrays.
In my forays into the source code, I do see various places where it has checks to see if the schema being handled is an array or not. But some logic in the generator is missing somewhere to ensure that the correct models are generated.
I was also curious to see if I could figure out what the "right" model would even look like for this case. I think the following changes would be needed:
RootModel to the import list from pydanticfrom openapi_client.models.null<str> import null<str> (although a line like this would be needed if the array was of schemas, rather than of primitive strings).class StringList(RootModel[List[str]]):to_dict and from_dict methods.The only other thing I'm not sure of is whether or not we'd need/want to_list and from_list methods. It seems like they'd make sense.
Bug Report Checklist
Description
A schema of
type: arraywith aoneOfinitemsproduces snippets of broken Python code like:openapi-generator version
7.2.0 (regression compared to 6.x)
OpenAPI declaration file content or url
https://github.com/hiddenswitch/ComfyUI/blob/wip/api/comfy/api/openapi.yaml
Logs on 7.3.0 (master):
Generation Details
openapi_python_config.yaml:
Steps to reproduce
See Collab notebook here https://colab.research.google.com/drive/18sXET4mnQLMrsxru2vumN7iuk1fVJEVr?usp=sharing
Observe
queue_tuplehas content likewhich is not valid Python and indicates a bug.
Related issues/PRs
Related to https://github.com/OpenAPITools/openapi-generator/issues/17745
Suggest a fix
Not sure what the underlying issue is, are
Arrayschemas unexpected? this works in 6.x.