Custom API tool: OpenAPI specification to support file uploads, and it can be used in workflow

[Sakura4036]

Self Checks

• [X] I have searched for existing issues search for existing issues, including closed ones.
• [X] I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
• [X] Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

I developed a pdf file parsing service with marker. The service accepts a file or files as a parameter. When publishing this as a custom tool, does it support file uploads in Dify v0.10.0? If it does support file uploads, how should I write the OpenAPI specification and enables the tool to use customized files variables as parameters in the workflow?

2. Additional context or comments

my tool schema now

...
  "paths": {
    "/batch_convert": {
      "post": {
        "summary": "批量转换PDF文件为Markdown",
        "requestBody": {
          "content": {
            "multipart/form-data": {
              "schema": {
                "type": "object",
                "properties": {
                  "files": {
                    "type": "array",
                    "items": {
                      "type": "string",
                      "format": "binary"
                    },
                    "description": "PDF文件列表"
                  }
                }
              }
            }
          }
...

dify workflow

However, in the workflow, the files parameter only accepts String, causing it to not use the sys.files or files variables

3. Can you help us with this feature?

• [ ] I am interested in contributing to this feature.

[WQL782795]

I encountered the same issue: The problem can be simply described as follows: when creating a custom tool using OpenAI-swagger, specifying type: array does not actually take effect, and it still behaves as string.

Here is the swagger content. Some information has been redacted and will need to be replaced for verification.

openapi: "3.1.0"
info:
  title: "OTMS接口示例"
  description: "用于查询割接方案的简单示例"
  version: "v1.0.0"
servers:
  - url: "http://xxxx:xxxxx/api"
    description: "OTMS接口地址"
paths:
  /otms-proxy/serviceAgent/rest/service-zhwg-cutover-stat/foreign/cnsiPublish/cnsi/changePlan:
    post:
      tags:
        - "otms接口"
      summary: "查询割接方案接口"
      operationId: "changePlanUsingPOST"
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                cutoverNoList:
                  type: "array"
                  items:
                    type: "string"
                  description: "割接编号列表，数组形式，例如 ['110303', '110305']"
                traceId:
                  type: "string"
                  description: "随机跟踪ID"
              required:
                - cutoverNoList
                - traceId
      responses:
        200:
          description: "请求成功"
        201:
          description: "资源已创建"
        401:
          description: "未授权"
        403:
          description: "禁止访问"
        404:
          description: "未找到资源"

[zolgear]

Duplicated #9322

[dosubot[bot]]

Hi, @Sakura4036. I'm Dosu, and I'm helping the Dify team manage their backlog. I'm marking this issue as stale.

Issue Summary:

• You inquired about Dify v0.10.0's support for file uploads in a custom API tool for parsing PDFs.
• You also asked for guidance on writing the OpenAPI specification to use file variables as parameters.
• WQL782795 noted a similar issue with type: array in OpenAPI behaving as a string.
• Zolgear mentioned this might be a duplicate of issue #9322.

Next Steps:

• Please confirm if this issue is still relevant to the latest version of Dify. If so, feel free to comment to keep the discussion open.
• If there is no further activity, this issue will be automatically closed in 15 days.

Thank you for your understanding and contribution!