`nullable` `int` model parameter treated as a file in multipart with 0.17.0, causing `httpx` `AttributeError` about openapi-python-client HOT 13 OPEN

@johnthagen when you get a chance, please check out #995 to see if that's closer to expected. I still have to do some cleanup, so it won't be perfect

from openapi-python-client.

@dbanty I installed the PR using:

python -m pip install git+https://github.com/openapi-generators/openapi-python-client.git@refs/pull/995/merge

Regenerated the client, tested my multipart endpoint, and it worked great using this PR! 🚀

from openapi-python-client.

Looking into this some more, the model I'm generating looks like:

@_attrs_define
class TRequest:
    file: Union[Unset, File] = UNSET
    parent: Union[None, Unset, int] = UNSET
    ...

parent is a primary key, so it's a simple int. But the new _get_kwargs generates

def _get_kwargs(
    id: int,
    *,
    body: TRequest,
) -> Dict[str, Any]:
    headers: Dict[str, Any] = {}

    _kwargs: Dict[str, Any] = {
        "method": "patch",
        "url": "/t/{id}/".format(
            id=id,
        ),
    }

    _body = body.to_multipart()

    _kwargs["files"] = _body

    _kwargs["headers"] = headers
    return _kwargs

When called like:

sync_detailed(
    1,
    client=client,
    body=TRequest(parent=2),
 )

This generates a kwargs in sync_detailed() that looks like:

{
  'files': {'parent': 4}, 
  'headers': {}, 
  'method': 'patch', 
  'url': '/t/2/'
}

And then it seems like the parent primary key int is being passed to httpx as if it were a File? Thus why httpx is trying to run read on it.

from openapi-python-client.

In contrast, the 0.16.0 created these kwargs which do work properly (passed through httpx and when processed by the server):

{
    "files": {"parent": (None, b"6", "text/plain")},
    "method": "patch",
    "url": "/t/2/",
}

from openapi-python-client.

I confirmed that this bug is still present in 0.17.2.

from openapi-python-client.

The regression seems to have come from

• #900

from openapi-python-client.

@dbanty Do you have any thoughts here? I think I've traced the issue about as far as I can. Thanks.

from openapi-python-client.

@johnthagen any chance that #938 fixes this for you? I haven't had a chance to test it out, but your validation would be enough for me!

from openapi-python-client.

@dbanty I tried this:

pip install git+https://github.com/openapi-generators/openapi-python-client.git@refs/pull/938/merge

from #938 and regenerated the client. I did see some changes to the generated to_multipart() methods in a number of my models, but the problem listed in this issue is still present.

from openapi-python-client.

I drilled down into the diff between 0.16.0 and 0.17.x again some more, I found the actual line that is causing the problem.

In 0.16.0, within to_multipart(), the line for parent was:

        parent = self.parent if isinstance(self.parent, Unset) else (None, str(self.parent).encode(), "text/plain")

But in 0.17.x it is changed to:

        parent: Union[None, Unset, int]
        if isinstance(self.parent, Unset):
            parent = UNSET
        else:
            parent = self.parent

And thus, this int isn't being properly encoded as other ints in the model are (the non-nullable ones are still being encoded as "text/plain").

Is there perhaps a logic bug because parent is nullable?

from openapi-python-client.

@dbanty Curious if you had had any chance to look into the tracing down in the comment above?

from openapi-python-client.

Yeah, I think the answer is quite messy and is going to require a lot of template logic. I think the right way to fix it is to completely separate out the json vs multipart template logic instead of continuing to try and reuse bits and pieces, since there are also weird things right now like checking if a value is unset even if it's required.

from openapi-python-client.

I first double checked that 0.19.0 stable release still causes this issue, and, as expected, it does.

from openapi-python-client.