Bundle with marketplace/github dependencies fails to install despite 200 OK response #240

New Issue

2026-02-16T01:15:04-05:00

yindo commented

2026-02-16 01:15:04 -05:00

Originally created by @takumi-ricoh on GitHub (Jan 28, 2026).

Self Checks

I have searched for existing issues, including closed ones.
I confirm that I am using English to submit this report.

Environment

Dify version: Self-hosted (Docker)
dify-plugin CLI version: v0.5.3
OS: Linux (Ubuntu)

Description

When installing a bundle (.difybndl) that contains marketplace or github dependencies via the Dify UI ("Install from local package file"), the installation fails with "Plugin loading error" (プラグインの読み込みエラー), even though the API returns HTTP 200 OK.

Note: Installing a standalone .difypkg file directly works without issues. Only bundle dependencies (marketplace/github type) fail.

Steps to reproduce

Initialize a bundle:

./dify-plugin-linux-amd64 bundle init
# Bundle name: my_bundle, Author: test

Add marketplace dependency:

./dify-plugin-linux-amd64 bundle append marketplace my_bundle --marketplace_pattern=langgenius/openai:0.2.8

Package the bundle:

./dify-plugin-linux-amd64 bundle package ./my_bundle

In Dify UI: Plugins → Install Plugin → Local Package File → Select my_bundle.difybndl

Expected behavior

The bundle should be parsed, marketplace dependencies should be resolved and downloaded, and all plugins should be installed successfully.

Actual behavior

The API endpoint POST /console/api/workspaces/current/plugin/upload/bundle returns 200 OK
However, the UI shows "Plugin loading error" (プラグインの読み込みエラー) for each dependency

The response body contains duplicate entries for the same plugin:

[
    {
        "type": "marketplace",
        "value": {
            "organization": "langgenius",
            "plugin": "openai",
            "version": "0.2.8"
        }
    },
    {
        "type": "marketplace",
        "value": {
            "organization": "langgenius",
            "plugin": "openai",
            "version": "0.2.8"
        }
    }
]

manifest.yaml content

name: my_bundle
labels:
    en_US: my_bundle
    ja_JP: my_bundle
    zh_Hans: my_bundle
    pt_BR: my_bundle
description:
    en_US: my_bundle
    ja_JP: my_bundle
    zh_Hans: my_bundle
    pt_BR: my_bundle
icon: icon.svg
version: 0.0.1
author: test
type: bundle
dependencies:
    - type: marketplace
      value:
        marketplace_pattern: langgenius/openai:0.2.8
tags: []

GitHub dependency also fails

The same error occurs with github type dependency:

dependencies:
    - type: github
      value:
        repo_pattern: langgenius/openai:0.2.8/openai.difypkg

Screenshots

(UI shows "プラグインの読み込みエラー - このプラグインはインストールされません" for each dependency)

Additional notes

The duplicate entries in the response body suggest a parsing or processing bug
Direct installation of .difypkg files works correctly - only bundle dependencies fail
The documentation at https://docs.dify.ai/en/develop-plugin/features-and-specs/advanced-development/bundle references dify-plugin command, but the actual CLI binary is named differently (e.g., dify-plugin-linux-amd64). Documentation update may be needed.

Originally created by @takumi-ricoh on GitHub (Jan 28, 2026). ### Self Checks - [x] I have searched for existing issues, including closed ones. - [x] I confirm that I am using English to submit this report. ### Environment - **Dify version**: Self-hosted (Docker) - **dify-plugin CLI version**: v0.5.3 - **OS**: Linux (Ubuntu) ### Description When installing a bundle (.difybndl) that contains marketplace or github dependencies via the Dify UI ("Install from local package file"), the installation fails with "Plugin loading error" (プラグインの読み込みエラー), even though the API returns HTTP 200 OK. **Note**: Installing a standalone .difypkg file directly works without issues. Only bundle dependencies (marketplace/github type) fail. ### Steps to reproduce 1. Initialize a bundle: ```bash ./dify-plugin-linux-amd64 bundle init # Bundle name: my_bundle, Author: test ``` 2. Add marketplace dependency: ```bash ./dify-plugin-linux-amd64 bundle append marketplace my_bundle --marketplace_pattern=langgenius/openai:0.2.8 ``` 3. Package the bundle: ```bash ./dify-plugin-linux-amd64 bundle package ./my_bundle ``` 4. In Dify UI: Plugins → Install Plugin → Local Package File → Select `my_bundle.difybndl` ### Expected behavior The bundle should be parsed, marketplace dependencies should be resolved and downloaded, and all plugins should be installed successfully. ### Actual behavior 1. The API endpoint `POST /console/api/workspaces/current/plugin/upload/bundle` returns **200 OK** 2. However, the UI shows **"Plugin loading error"** (プラグインの読み込みエラー) for each dependency 3. The response body contains **duplicate entries** for the same plugin: ```json [ { "type": "marketplace", "value": { "organization": "langgenius", "plugin": "openai", "version": "0.2.8" } }, { "type": "marketplace", "value": { "organization": "langgenius", "plugin": "openai", "version": "0.2.8" } } ] ``` ### manifest.yaml content ```yaml name: my_bundle labels: en_US: my_bundle ja_JP: my_bundle zh_Hans: my_bundle pt_BR: my_bundle description: en_US: my_bundle ja_JP: my_bundle zh_Hans: my_bundle pt_BR: my_bundle icon: icon.svg version: 0.0.1 author: test type: bundle dependencies: - type: marketplace value: marketplace_pattern: langgenius/openai:0.2.8 tags: [] ``` ### GitHub dependency also fails The same error occurs with github type dependency: ```yaml dependencies: - type: github value: repo_pattern: langgenius/openai:0.2.8/openai.difypkg ``` ### Screenshots <img width="498" height="354" alt="Image" src="https://github.com/user-attachments/assets/f5f1143a-e8c4-426d-a36c-e78abb292470" /> *(UI shows "プラグインの読み込みエラー - このプラグインはインストールされません" for each dependency)* ### Additional notes 1. The duplicate entries in the response body suggest a parsing or processing bug 2. Direct installation of `.difypkg` files works correctly - only bundle dependencies fail 3. The documentation at https://docs.dify.ai/en/develop-plugin/features-and-specs/advanced-development/bundle references `dify-plugin` command, but the actual CLI binary is named differently (e.g., `dify-plugin-linux-amd64`). Documentation update may be needed.

yindo added the documentation bug labels 2026-02-16 01:15:04 -05:00

yindo commented

2026-02-16 01:15:05 -05:00

@dosubot[bot] commented on GitHub (Jan 28, 2026):

Hi @takumi-ricoh! I'm Dosu and I’m helping the dify-plugin-daemon team.

There are a few likely causes for your bundle dependency installation failures and duplicate entries:

The API always returns HTTP 200 OK for bundle uploads, even if there are errors during processing. Actual errors are only surfaced in the response body or UI, not via HTTP status codes (source).
The bundle installation logic appends dependency entries to the result list without deduplication, which can lead to duplicate entries in the API response (source).
"Plugin loading error" is often caused by environment or network issues in Docker: missing system dependencies, proxy misconfiguration, or CA certificate problems can prevent the daemon from resolving and installing marketplace/github dependencies (source).
If ENFORCE_LANGGENIUS_PLUGIN_SIGNATURES is enabled (default: true), marketplace plugins claiming to be from Langgenius but lacking a valid signature will be blocked, causing silent install failures (source).

Troubleshooting steps:

Check your plugin_daemon logs for signature verification errors or network failures.
Make sure your Docker environment has correct PLUGIN_DAEMON_URL and no_proxy settings, and that the container can reach the marketplace or GitHub.
If you're behind a corporate proxy, you may need to build a custom plugin_daemon image with your CA certificate baked in, as the Go runtime may ignore runtime CA updates (source).

There is no clear evidence of a fix for the duplicate entry bug or a robust workaround for bundle dependency failures in the current codebase. Direct installation of .difypkg files works because it bypasses dependency resolution logic that is more likely to hit these environment or parsing bugs.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

@dosubot[bot] commented on GitHub (Jan 28, 2026):  Hi @takumi-ricoh! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify-plugin-daemon team.  There are a few likely causes for your bundle dependency installation failures and duplicate entries: - The API always returns HTTP 200 OK for bundle uploads, even if there are errors during processing. Actual errors are only surfaced in the response body or UI, not via HTTP status codes [(source)](https://github.com/langgenius/dify-plugin-daemon/blob/f272e6c3fcd8a18c6ff571d7fcbfde857f63ef99/internal/server/controllers/plugins.go#L28-L89). - The bundle installation logic appends dependency entries to the result list without deduplication, which can lead to duplicate entries in the API response [(source)](https://github.com/langgenius/dify-plugin-daemon/pull/458). - "Plugin loading error" is often caused by environment or network issues in Docker: missing system dependencies, proxy misconfiguration, or CA certificate problems can prevent the daemon from resolving and installing marketplace/github dependencies [(source)](https://github.com/langgenius/dify-plugin-daemon/issues/373#issuecomment-3029339624). - If ENFORCE_LANGGENIUS_PLUGIN_SIGNATURES is enabled (default: true), marketplace plugins claiming to be from Langgenius but lacking a valid signature will be blocked, causing silent install failures [(source)](https://github.com/langgenius/dify-plugin-daemon/pull/458). Troubleshooting steps: - Check your plugin_daemon logs for signature verification errors or network failures. - Make sure your Docker environment has correct `PLUGIN_DAEMON_URL` and `no_proxy` settings, and that the container can reach the marketplace or GitHub. - If you're behind a corporate proxy, you may need to build a custom plugin_daemon image with your CA certificate baked in, as the Go runtime may ignore runtime CA updates [(source)](https://github.com/langgenius/dify-plugin-daemon/issues/329#issuecomment-2948505589). There is no clear evidence of a fix for the duplicate entry bug or a robust workaround for bundle dependency failures in the current codebase. Direct installation of `.difypkg` files works because it bypasses dependency resolution logic that is more likely to hit these environment or parsing bugs.  *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- How did I do? [Good](https://app.dosu.dev/response-feedback/42cc3192-07af-4446-87b3-2f2243cc5a3a?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/42cc3192-07af-4446-87b3-2f2243cc5a3a?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/42cc3192-07af-4446-87b3-2f2243cc5a3a?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/42cc3192-07af-4446-87b3-2f2243cc5a3a?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/42cc3192-07af-4446-87b3-2f2243cc5a3a?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/42cc3192-07af-4446-87b3-2f2243cc5a3a?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/42cc3192-07af-4446-87b3-2f2243cc5a3a?feedback_type=other) [![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=There%20are%20a%20few%20likely%20causes%20for%20your%20bundle%20dependency%20installation%20failures%20and%20duplicate%20entries%3A%0A%0A-%20The%20API%20always%20returns%20HTTP%20200%20OK%20for%20bundle%20uploads%2C%20even%20if%20there%20are%20errors%20during%20processing.%20Actual%20errors%20are%20only%20surfaced%20in%20the%20response%20body%20or%20UI%2C%20not%20via%20HTTP%20status%20codes%20%5B%28source%29%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/blob/f272e6c3fcd8a18c6ff571d7fcbfde857f63ef99/internal/server/controllers/plugins.go%23L28-L89%29.%0A-%20The%20bundle%20installation%20logic%20appends%20dependency%20entries%20to%20the%20result%20list%20without%20deduplication%2C%20which%20can%20lead%20to%20duplicate%20entries%20in%20the%20API%20response%20%5B%28source%29%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/pull/458%29.%0A-%20%22Plugin%20loading%20error%22%20is%20often%20caused%20by%20environment%20or%20network%20issues%20in%20Docker%3A%20missing%20system%20dependencies%2C%20proxy%20misconfiguration%2C%20or%20CA%20certificate%20problems%20can%20prevent%20the%20daemon%20from%20resolving%20and%20installing%20marketplace/github%20dependencies%20%5B%28source%29%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/issues/373%23issuecomment-3029339624%29.%0A-%20If%20ENFORCE_LANGGENIUS_PLUGIN_SIGNATURES%20is%20enabled%20%28default%3A%20true%29%2C%20marketplace%20plugins%20claiming%20to%20be%20from%20Langgenius%20but%20lacking%20a%20valid%20signature%20will%20be%20blocked%2C%20causing%20silent%20install%20failures%20%5B%28source%29%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/pull/458%29.%0A%0ATroubleshooting%20steps%3A%0A-%20Check%20your%20plugin_daemon%20logs%20for%20signature%20verification%20errors%20or%20network%20failures.%0A-%20Make%20sure%20your%20Docker%20environment%20has%20correct%20%60PLUGIN_DAEMON_URL%60%20and%20%60no_proxy%60%20settings%2C%20and%20that%20the%20container%20can%20reach%20the%20marketplace%20or%20GitHub.%0A-%20If%20you%27re%20behind%20a%20corporate%20proxy%2C%20you%20may%20need%20to%20build%20a%20custom%20plugin_daemon%20image%20with%20your%20CA%20certificate%20baked%20in%2C%20as%20the%20Go%20runtime%20may%20ignore%20runtime%20CA%20updates%20%5B%28source%29%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/issues/329%23issuecomment-2948505589%29.%0A%0AThere%20is%20no%20clear%20evidence%20of%20a%20fix%20for%20the%20duplicate%20entry%20bug%20or%20a%20robust%20workaround%20for%20bundle%20dependency%20failures%20in%20the%20current%20codebase.%20Direct%20installation%20of%20%60.difypkg%60%20files%20works%20because%20it%20bypasses%20dependency%20resolution%20logic%20that%20is%20more%20likely%20to%20hit%20these%20environment%20or%20parsing%20bugs.) [![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot) [![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify-plugin-daemon/issues/591)

yindo commented

2026-02-16 01:15:05 -05:00

@takumi-ricoh commented on GitHub (Jan 29, 2026):

Thanks for the analysis @dosu.

However, I don't think this is a network/proxy issue because:

Direct .difypkg installation works - I can successfully install langgenius-openai_0.2.8.difypkg directly from the Dify UI (Install from local package file). This means the plugin_daemon can reach the marketplace and download plugins without issues.
Only bundle dependencies fail - The exact same plugin that installs successfully as a standalone .difypkg fails when referenced as a marketplace dependency in a bundle.

This suggests the issue is specifically in the bundle dependency resolution logic, not network connectivity.

@takumi-ricoh commented on GitHub (Jan 29, 2026): Thanks for the analysis @dosu. However, I don't think this is a network/proxy issue because: 1. **Direct .difypkg installation works** - I can successfully install `langgenius-openai_0.2.8.difypkg` directly from the Dify UI (Install from local package file). This means the plugin_daemon can reach the marketplace and download plugins without issues. 2. **Only bundle dependencies fail** - The exact same plugin that installs successfully as a standalone .difypkg fails when referenced as a marketplace dependency in a bundle. This suggests the issue is specifically in the **bundle dependency resolution logic**, not network connectivity.

yindo commented

2026-02-16 01:15:05 -05:00

@dosubot[bot] commented on GitHub (Jan 29, 2026):

You're right—since direct .difypkg installs work, the issue is almost certainly in the bundle dependency resolution logic, not network or proxy configuration.

The bundle install path parses dependencies from your manifest and passes them to the install service, but there’s no deduplication or extra error handling at the parsing layer. If the manifest or the install logic encounters a problem (like a signature check or a parsing bug), the API still returns HTTP 200 OK, but the UI shows "Plugin loading error" for each dependency. Duplicate entries in the API response can happen because the bundle install logic appends dependencies without filtering out repeats or handling failures cleanly, which matches what you’re seeing source source.

There’s no open issue or recent PR that directly fixes this bundle dependency bug or the duplicate entry problem. The direct .difypkg install path doesn’t touch the bundle parsing logic, which is why it works. At the moment, there’s no documented workaround—most advice is to check your manifest and environment, but your setup looks correct.

If you need a temporary solution, installing plugins individually as .difypkg files is the only reliable method until the bundle logic is improved.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

@dosubot[bot] commented on GitHub (Jan 29, 2026):  You're right—since direct .difypkg installs work, the issue is almost certainly in the bundle dependency resolution logic, not network or proxy configuration. The bundle install path parses dependencies from your manifest and passes them to the install service, but there’s no deduplication or extra error handling at the parsing layer. If the manifest or the install logic encounters a problem (like a signature check or a parsing bug), the API still returns HTTP 200 OK, but the UI shows "Plugin loading error" for each dependency. Duplicate entries in the API response can happen because the bundle install logic appends dependencies without filtering out repeats or handling failures cleanly, which matches what you’re seeing [source](https://github.com/langgenius/dify-plugin-daemon/blob/f272e6c3fcd8a18c6ff571d7fcbfde857f63ef99/internal/server/controllers/plugins.go#L28-L90) [source](https://github.com/langgenius/dify-plugin-daemon/blob/f272e6c3fcd8a18c6ff571d7fcbfde857f63ef99/pkg/entities/bundle_entities/dependency.go#L14-L237). There’s no open issue or recent PR that directly fixes this bundle dependency bug or the duplicate entry problem. The direct .difypkg install path doesn’t touch the bundle parsing logic, which is why it works. At the moment, there’s no documented workaround—most advice is to check your manifest and environment, but your setup looks correct. If you need a temporary solution, installing plugins individually as .difypkg files is the only reliable method until the bundle logic is improved.  *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- How did I do? [Good](https://app.dosu.dev/response-feedback/3833568a-f7c0-468d-8a9b-9d91dac7c650?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/3833568a-f7c0-468d-8a9b-9d91dac7c650?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/3833568a-f7c0-468d-8a9b-9d91dac7c650?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/3833568a-f7c0-468d-8a9b-9d91dac7c650?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/3833568a-f7c0-468d-8a9b-9d91dac7c650?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/3833568a-f7c0-468d-8a9b-9d91dac7c650?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/3833568a-f7c0-468d-8a9b-9d91dac7c650?feedback_type=other) [![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=You%27re%20right%E2%80%94since%20direct%20.difypkg%20installs%20work%2C%20the%20issue%20is%20almost%20certainly%20in%20the%20bundle%20dependency%20resolution%20logic%2C%20not%20network%20or%20proxy%20configuration.%0A%0AThe%20bundle%20install%20path%20parses%20dependencies%20from%20your%20manifest%20and%20passes%20them%20to%20the%20install%20service%2C%20but%20there%E2%80%99s%20no%20deduplication%20or%20extra%20error%20handling%20at%20the%20parsing%20layer.%20If%20the%20manifest%20or%20the%20install%20logic%20encounters%20a%20problem%20%28like%20a%20signature%20check%20or%20a%20parsing%20bug%29%2C%20the%20API%20still%20returns%20HTTP%20200%20OK%2C%20but%20the%20UI%20shows%20%22Plugin%20loading%20error%22%20for%20each%20dependency.%20Duplicate%20entries%20in%20the%20API%20response%20can%20happen%20because%20the%20bundle%20install%20logic%20appends%20dependencies%20without%20filtering%20out%20repeats%20or%20handling%20failures%20cleanly%2C%20which%20matches%20what%20you%E2%80%99re%20seeing%20%5Bsource%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/blob/f272e6c3fcd8a18c6ff571d7fcbfde857f63ef99/internal/server/controllers/plugins.go%23L28-L90%29%20%5Bsource%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/blob/f272e6c3fcd8a18c6ff571d7fcbfde857f63ef99/pkg/entities/bundle_entities/dependency.go%23L14-L237%29.%0A%0AThere%E2%80%99s%20no%20open%20issue%20or%20recent%20PR%20that%20directly%20fixes%20this%20bundle%20dependency%20bug%20or%20the%20duplicate%20entry%20problem.%20The%20direct%20.difypkg%20install%20path%20doesn%E2%80%99t%20touch%20the%20bundle%20parsing%20logic%2C%20which%20is%20why%20it%20works.%20At%20the%20moment%2C%20there%E2%80%99s%20no%20documented%20workaround%E2%80%94most%20advice%20is%20to%20check%20your%20manifest%20and%20environment%2C%20but%20your%20setup%20looks%20correct.%0A%0AIf%20you%20need%20a%20temporary%20solution%2C%20installing%20plugins%20individually%20as%20.difypkg%20files%20is%20the%20only%20reliable%20method%20until%20the%20bundle%20logic%20is%20improved.) [![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot) [![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify-plugin-daemon/issues/591)

yindo commented

2026-02-16 01:15:05 -05:00

@takumi-ricoh commented on GitHub (Jan 30, 2026):

@dosu Thanks for confirming.

So to summarize, this is a confirmed bug in the bundle dependency resolution logic:

Duplicate entries bug - Bundle install logic appends dependencies without deduplication
Silent failure - API returns 200 OK but UI shows "Plugin loading error"
No existing fix - No open issue or PR addresses this problem

Can you confirm this should be labeled as a bug and kept open for the maintainers to review?

@takumi-ricoh commented on GitHub (Jan 30, 2026): @dosu Thanks for confirming. So to summarize, this is a **confirmed bug** in the bundle dependency resolution logic: 1. **Duplicate entries bug** - Bundle install logic appends dependencies without deduplication 2. **Silent failure** - API returns 200 OK but UI shows "Plugin loading error" 3. **No existing fix** - No open issue or PR addresses this problem Can you confirm this should be labeled as a **bug** and kept open for the maintainers to review?

yindo commented

2026-02-16 01:15:05 -05:00

@dosubot[bot] commented on GitHub (Jan 30, 2026):

Yes, this should be labeled as a bug and kept open for maintainers to review. The duplicate dependency entries and silent failures during bundle installation are unintended behaviors in the bundle dependency resolution logic, and there is no existing fix or open issue/PR addressing them. The evidence from both user reports and code analysis confirms this is a real issue in the current implementation.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

@dosubot[bot] commented on GitHub (Jan 30, 2026):  Yes, this should be labeled as a bug and kept open for maintainers to review. The duplicate dependency entries and silent failures during bundle installation are unintended behaviors in the bundle dependency resolution logic, and there is no existing fix or open issue/PR addressing them. The evidence from both user reports and code analysis confirms this is a real issue in the current implementation.  *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- How did I do? [Good](https://app.dosu.dev/response-feedback/b3a2c664-6031-45d5-904d-f60295971648?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/b3a2c664-6031-45d5-904d-f60295971648?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/b3a2c664-6031-45d5-904d-f60295971648?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/b3a2c664-6031-45d5-904d-f60295971648?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/b3a2c664-6031-45d5-904d-f60295971648?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/b3a2c664-6031-45d5-904d-f60295971648?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/b3a2c664-6031-45d5-904d-f60295971648?feedback_type=other) [![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=Yes%2C%20this%20should%20be%20labeled%20as%20a%20bug%20and%20kept%20open%20for%20maintainers%20to%20review.%20The%20duplicate%20dependency%20entries%20and%20silent%20failures%20during%20bundle%20installation%20are%20unintended%20behaviors%20in%20the%20bundle%20dependency%20resolution%20logic%2C%20and%20there%20is%20no%20existing%20fix%20or%20open%20issue/PR%20addressing%20them.%20The%20evidence%20from%20both%20user%20reports%20and%20code%20analysis%20confirms%20this%20is%20a%20real%20issue%20in%20the%20current%20implementation.) [![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot) [![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify-plugin-daemon/issues/591)

yindo referenced this issue

2026-02-16 01:15:50 -05:00

[PR #240] [MERGED] feat: add backward compatibility for LLMResultChunk and new test case #393

Sign in to join this conversation.

Branches Tags

main

build/fix-serverless-runtime-error-propagation

gh-pages

build/test-document2

build/test-document

build/onboarding-ui

build/slim-extract

codex/depot-builds

codex/mac-runner-benchmark

feat/storage-path-prefix

feat/multi-db-user

feat/slim-action

deploy/dev

feat/dify-cli

feat/add-e2e

build/pg-bouncer

codex/add-multimodal-rerank-and-embedding-apis

refactor/local-runtime

build/multimodal-embeddings

codex/refactor-routine.submit-label-handling

codex/refactor-service-layer-based-on-provided-plan

feat/trigger-response

feat/trigger

build/trigger

deploy/trigger-dev

codex/remove-claude-code-reviewer-from-github-ci

codex/add-manifest-check-to-upload-endpoint

feat/no-root-dockerfile

fix/json-schema

fix/blocking-anthorized-langgenius

454-bump-cli-template

build/datasource

feat/datasource

bump-cloud-kit

feat/rag-tag

fix/change-session-not-found-to-400

feat/plugin-readme

add-claude-github-actions-1756274550417

docs/comprehensive-development-documentation

chore/remove-json-schema-validation-error

71cef04

fix/missing-parameter-type

fix/sessions-log

fix/template.env

bump/go-git

build/oauth

feat/oauth-refresh-token

feat/plugin-oauth

feat/tool-oauth-cli

build/plugin-oauth

feat/readme-i18n

fix/memory-leak

feat/icon-dark

feat/default-icon

plugin_launch_concurent

feat/collect-active-requests

feat/dark-icon

feat/support-structured-llm-output

feat/dynamic-selector

fix/reduce-logs

feat/decode-plugin-package

feat/db-extras

fix/backwards-invocation-overflow

feat/length-prefixed-chunking

fix/http-request-reader-header

chore/unify-configurations

fix/hardcoded-serverless-runtime-timeout

fix/cmd

fix/signature

refactor/implement-gen-routes

fix/redis-lock

refactor/codegen

feat/add-authorized-category

chore/style

feat/run-plugin-cli

reduce/run-once

feat/reinstall-serverless-runtime

feat/support-setup-process

fix/apply-stdio-buffer-size

chore/add-warning-messages-to-installed-bucket

feat/repo

enhance/stdio

feat/make-buffer-size-configurable

fix/moderation-init

fix/only-validate-profile-on-quick-mode

feat/support-quick-init-plugins

refactor/oauth-parameters

feat/oauth

refactor/simplify-plugin-invocation

test/integration-test-for-plugins

fix/backwards-compatible-to-llm-result-chunk

feat/auto-scale

enhance/reduce-ci-tests

fix/cli-ci

enhance/removes-llm-result-prompt-messages

fix/disable-benchmark-logs

benchmark/local-runtime

chore/remove-useless-benchmark

feat/benchmark

feat/fetch-app-info

fix/windows-remap-assets

fix/skip-hidden-file

feat/stream-tool-blob-message

fix/path-travel

feat/template-add-ci

enhance/version-compare

feat/sign-apple-os-cli

feat/support-minimal-dify-version-required

refactor/stdip

feat/add-serverless-connector-launching-timeout

fix/remove-prompt_messages-from-llm-result-chunk

feat/standardize-plugin-sdk-versions

chore/update-docs-and-refine-wording

update/readme-cli

fix/infinity-environment-setup

fix/cbor-unmarshaling

fix/use-aws-iam-baseendpoint

fix/lost-query-params-in-endpoint

fix/tiktoken

cohre/update-readme

fix/redis-tests

fix/friendly-identity

fix/marshal-any-map

chore/upgrade-ants

fix/graceful-precompile

enhance/tiktoken

feat/graceful-shutdown

fix/close-serverless-response

fix/correct-cli-guide

fix/plugin-active-log

fix/remove-proxy-args-from-uv

fix/endpoint-hook-url

fix/ci-credentials

feat/disable-gevent

fix/add-gcc

fix/hardcoded-endpoint-timeout

fix/bump-cli-sdk-version

fix/deadloop-when-redis-disconnect

fix/enhence/speed-up-environment-setup

enhance/introduce-uv

fix/change-default-db

fix/deadlock

readme

chore/env.example

feat/add-action-in-url

fix/add-more-pip-args

fix/optimize-local-heartbeat

optimize/db-init

fix/optimize-internal-server-error

fix/increase-default-plugin-max-execution-timeout

fix/force-patch-older-version

enhance/increase-installing-process

LICENSE

fix/set-user-id-to-unrequired

fix/max-launching-concurrent

improve/error-handing-in-serverless

refactor/json-unmarshaler-enhancement

fix/add-pip-mirror-url

enhance/serverless-connector

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: langgenius/dify-plugin-daemon#240