langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 20:15:31 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Enhance Plugin SDK to Support File Return Types for Model Plugins #12850

New Issue
Closed
opened 2026-02-21 19:09:22 -05:00 by yindo · 1 comment
yindo commented 2026-02-21 19:09:22 -05:00
Owner
Copy Link
Copy Source

Originally created by @hejuntt1014 on GitHub (Apr 13, 2025).

Self Checks

  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
  • 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.

Currently, the plugin SDK (dify-plugin-sdk) defines model plugin return types in Plugins Schema Specification Model as follows:

  • Streaming mode: returns Generator[LLMResultChunk]
  • Non-streaming mode: returns LLMResult

However, both LLMResultChunk and LLMResult currently only support textual content, which significantly limits the capability of model plugins—especially for models that can generate images or other file-based outputs.

This makes it currently impossible to develop model plugins for image-generating models using the official SDK.

Suggestion:

Consider enhancing the SDK to support file return types in model plugins, similar to how tool-type plugins can return files. Ideally, this could be achieved by extending the existing return schema to include an optional files field (or similar), which can handle URLs or base64-encoded content for generated files.

Image

2. Additional context or comments

Many cutting-edge models, such as Gemini 2.0 Flash (Image Generation) Experimental and the latest from OpenAI, have already supported multimodal input and output, including image generation capabilities.

We hope the model type plugin interface in the SDK can support returning images directly—similar to what's shown in the example below.
(Due to current SDK limitations, the image output in the example is implemented by uploading the generated image to get a remote URL.)

Enabling native file/image return support for model plugins would allow developers to fully leverage the capabilities of these new multimodal models within the Dify ecosystem.

Image

Image

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @hejuntt1014 on GitHub (Apr 13, 2025). ### Self Checks - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [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. Currently, the plugin SDK (`dify-plugin-sdk`) defines model plugin return types in `Plugins Schema Specification Model` as follows: - **Streaming mode**: returns `Generator[LLMResultChunk]` - **Non-streaming mode**: returns `LLMResult` However, both `LLMResultChunk` and `LLMResult` currently only support **textual content**, which significantly limits the capability of model plugins—especially for models that can generate **images or other file-based outputs**. This makes it currently impossible to develop model plugins for image-generating models using the official SDK. ### Suggestion: Consider enhancing the SDK to support **file return types** in model plugins, similar to how tool-type plugins can return files. Ideally, this could be achieved by extending the existing return schema to include an optional `files` field (or similar), which can handle URLs or base64-encoded content for generated files. ![Image](https://github.com/user-attachments/assets/9baabbae-7fac-4d4d-907e-954f4013e003) ### 2. Additional context or comments Many cutting-edge models, such as Gemini 2.0 Flash (Image Generation) Experimental and the latest from OpenAI, have already supported multimodal input and output, including image generation capabilities. We hope the model type plugin interface in the SDK can support returning images directly—similar to what's shown in the example below. (Due to current SDK limitations, the image output in the example is implemented by uploading the generated image to get a remote URL.) Enabling native file/image return support for model plugins would allow developers to fully leverage the capabilities of these new multimodal models within the Dify ecosystem. ![Image](https://github.com/user-attachments/assets/7925e42f-a118-430c-9e8a-193e6e6e6b30) ![Image](https://github.com/user-attachments/assets/92e74d22-356e-45eb-bff9-fcb3fc728ce3) ### 3. Can you help us with this feature? - [ ] I am interested in contributing to this feature.
yindo added the 💪 enhancement label 2026-02-21 19:09:22 -05:00
yindo closed this issue 2026-02-21 19:09:22 -05:00
yindo commented 2026-02-21 19:09:22 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (May 14, 2025):

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

Issue Summary:

  • Enhancement proposed for dify-plugin-sdk to support file return types.
  • Current SDK supports only textual content, limiting multimodal model functionality.
  • Suggestion to add a files field for URLs or base64-encoded content.
  • No comments or activity since the issue was opened.

Next Steps:

  • Please confirm if this enhancement is still relevant to the latest version of the Dify repository by commenting here.
  • If no updates are provided, the issue will be automatically closed in 15 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (May 14, 2025): Hi, @hejuntt1014. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog. I'm marking this issue as stale. **Issue Summary:** - Enhancement proposed for `dify-plugin-sdk` to support file return types. - Current SDK supports only textual content, limiting multimodal model functionality. - Suggestion to add a `files` field for URLs or base64-encoded content. - No comments or activity since the issue was opened. **Next Steps:** - Please confirm if this enhancement is still relevant to the latest version of the Dify repository by commenting here. - If no updates are provided, the issue will be automatically closed in 15 days. Thank you for your understanding and contribution!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 💪 enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#12850
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?