Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] file uploads not supported by the Rust generator #17822

Open
2 of 6 tasks
qrilka opened this issue Feb 8, 2024 · 5 comments
Open
2 of 6 tasks

[BUG] file uploads not supported by the Rust generator #17822

qrilka opened this issue Feb 8, 2024 · 5 comments

Comments

@qrilka
Copy link

qrilka commented Feb 8, 2024

Bug Report Checklist

  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator (example)?
  • Have you tested with the latest master to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?
  • [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description

It's not clear how the project documents file upload support. But according to https://openapi-generator.tech/docs/generators/rust/ both File data type and FormMultipart are implemented. In practice the generated code contains just a TODO.
Side comment: file parameter becomes encoded as file: std::path::PathBuf which makes it impossible to use the generated code from WASM.

openapi-generator version
$ openapi-generator-cli --version
openapi-generator-cli 7.0.1

Also checked the latest templates in master

OpenAPI declaration file content or url
            "UploadRequest": {
                "properties": {
                    "file": {
                        "format": "binary",
                        "type": "string"
                    }
                },
                "required": [
                    "file"
                ],
                "type": "object"
            }
Generation Details

In the generated Rust code I see

    // TODO: support file upload for 'file' parameter

Reflecting the template

// TODO: support file upload for '{{{baseName}}}' parameter

Steps to reproduce

Create an endpoint with response body with "content": "multipart/form-data" and containing file parameter with format "binary", and type "string. Run Rust generator for this API spec.

Related issues/PRs

#16167

Suggest a fix

Create an explicit ticket about file support implementation and make it visible on the website that it's still missing.

@skyl
Copy link

skyl commented Nov 15, 2024

Here is a spec that show the problem if it would be helpful
openapi.json

I have no idea if this might be helpful but it's what copilot says in the interface about that TODO line:

{{#supportAsync}}
let mut local_var_form = reqwest::multipart::Form::new();
{{#formParams}}
{{#isFile}}
if let Some(local_var_file_path) = {{{paramName}}} {
    match tokio::fs::File::open(local_var_file_path).await {
        Ok(file) => {
            let form_part = reqwest::multipart::Part::stream(file);
            local_var_form = local_var_form.part("{{{baseName}}}", form_part);
        },
        Err(err) => {
            return Err(Error::FileOpenError(err));
        }
    }
}
{{/isFile}}
{{/formParams}}
local_var_req_builder = local_var_req_builder.multipart(local_var_form);
{{/supportAsync}}

This is still a problem on 7.9.0 but I haven't tried main.

@vincent-herlemont
Copy link

For the implementation of this issue, what interface should we have?

  • Should we keep the file path as input and read the file inside the function?
  • Or should we pass a stream reader directly as a parameter?

@fage88
Copy link

fage88 commented Dec 4, 2024

Stream reader would be my preference

@wing328
Copy link
Member

wing328 commented Dec 4, 2024

Should we keep the file path as input and read the file inside the function?

that's what i prefer as it will be a backward compatible change. otherwise, we will need an option for fallback.

@vincent-herlemont
Copy link

@wing328 Thanks for the guidance, I have started a PR here: #20242.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants