openapi-generators / openapi-generators/openapi-python-client

Upload file logic seems to be wrong on 3.1 schema

Ouverte
#1,417 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Langage dominant
Python
Étoiles
2k
Forks
293
Merge moyen
34 min
PR mergées (30 j)
1

Description

Describe the bug
I just upgraded my API, and the schema changed from 3.0 to 3.1. The uploads suddenly broke. It seems that the code generated for the body class now looks like this:

    file: str
 
    ...
    def to_multipart(self) -> types.RequestFiles:
        files: types.RequestFiles = []

        files.append(("file", (None, str(self.file).encode(), "text/plain")))

        for prop_name, prop in self.additional_properties.items():
            files.append((prop_name, (None, str(prop).encode(), "text/plain")))

        return files

While the old looked like this:

    file: File

    python
    def to_multipart(self) -> types.RequestFiles:
        files: types.RequestFiles = []

        files.append(("file", self.file.to_tuple()))

        for prop_name, prop in self.additional_properties.items():
            files.append((prop_name, (None, str(prop).encode(), "text/plain")))

        return files

Where the File object is this:

@define
class File:
    """Contains information for file uploads"""

    payload: BinaryIO
    file_name: str | None = None
    mime_type: str | None = None

    def to_tuple(self) -> FileTypes:
        """Return a tuple representation that httpx will accept for multipart/form-data"""
        return self.file_name, self.payload, self.mime_type

OpenAPI Spec File
A link to an OpenAPI document which produces this issue. Ideally, write a minimal reproduction only containing the problematic pieces.

The API spec for the body (new 3.1):

          "file": {
            "type": "string",
            "contentMediaType": "application/octet-stream",
            "title": "File"
          }

Old (3.0) schema:

          "file": {
            "type": "string",
            "format": "binary",
            "title": "File"
          }

Desktop:

  • OS: [e.g. macOS 10.15.1]: MacOS (M4) 26.3.1
  • Python Version: [e.g. 3.8.0]: 3.11.14
  • openapi-python-client version [e.g. 0.1.0]: 0.28.3

Additional context
I have some code pre-massaging around a different name-related issue and adding this to the pre-processing before this tool is called fixed it, but it's definitely more of a temporary workaround type of thing:

for prop in props.values():
      if prop.get("contentMediaType") == "application/octet-stream":
          prop["format"] = "binary"

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par reproduire la classe de body générée à partir du schéma OpenAPI 3.1 fourni et comparez-la avec le schéma 3.0 en utilisant format: binary. Suivez la manière dont contentMediaType: application/octet-stream est interprété lors de la génération ; c’est terminé lorsque le champ généré utilise File et que la sérialisation multipart appelle to_tuple() comme dans l’ancienne sortie.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
openapi, python
Domaine
api, tooling
Type d'issue
Bug
Difficulté
3/5
Temps estimé
1-2 jours
Activité
Calme
Clarté
Plutôt claire
Accessibilité débutants
55/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.