Optional date-time attribute with value None gets isoparse'd

[ololobus]

Describe the bug
I have a similar problem to #456, but in my case date-time attribute isn't marked as required. Yet, the model's from_dict method has following code:

_retry_at = d.pop("retry_at", UNSET)
retry_at: Union[Unset, datetime.datetime]
if isinstance(_retry_at, Unset):
    retry_at = UNSET
else:
    retry_at = isoparse(_retry_at)

which tries to parse None value if there is no retry_at in the server response.

To Reproduce
Client is generated like this

poetry run openapi-python-client generate --path ../swagger/$(API_VERSION)/swagger.json

Expected behavior
Client doesn't try to parse absent date-time attributes in the response.

OpenAPI Spec File

{
    "openapi": "3.0.0",
    "servers": [
        {
            "url": "/api/v1"
        }
    ],
    "components": {
        "schemas": {
            "Operation": {
                "type": "object",
                "required": [
                    "id"
                ],
                "properties": {
                    "id": {
                        "type": "string"
                    },
                    "retry_at": {
                        "type": "string",
                        "format": "date-time"
                    }
                }
            }
        }
    }
}

Desktop (please complete the following information):

• OS: Linux, PopOS 22
• Python Version: 3.9.0
• openapi-python-client version: 0.11.6

[dbanty]

It sounds to me like the server is responding with a null for retry_at like this:

{
  "id": "something",
  "retry_at": null
}

That would result in a None Python-side, which, per the schema, is invalid. If the property were omitted, like this:

{
  "id": "something"
}

Then the value of _retry_at would be UNSET, not None and it would not error.

So it sounds like the schema does not accurately describe the behavior of the server, and the definition of retry_at should look more like this:

{
    "type": "string",
    "format": "date-time",
    "nullable": true
}

[ololobus]

OK, that was really stupid... I have two versions of the API, new v2 and legacy v1 one. And I use both in a single regression test, so I double-checked that response doesn't contain null-attributes, but that was v2, not v1, which was indeed misbehaving.

Thank you for your time and reply, and really sorry for the buzz.

[dbanty]

No problem, glad you figured it out!