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

[takumi-ricoh]

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

1. Initialize a bundle:

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

2. Add marketplace dependency:

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

3. Package the bundle:

   ./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:

   [
       {
           "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

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.

[dosubot]

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}

  

[takumi-ricoh]

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.

[dosubot]

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}

  

[takumi-ricoh]

@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?

[dosubot]

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}