debug plugin error:no available node, plugin runtime not found #232

New Issue

Open

opened 2026-02-16 01:15:03 -05:00 by yindo · 3 comments

yindo commented 2026-02-16 01:15:03 -05:00

Owner

Copy Link

Copy Source

Originally created by @gaoding-hailang on GitHub (Jan 23, 2026).

Self Checks

To make sure we get to you in time, please check the following :)

• 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."

Versions

1. dify-plugin-daemon 0.5.2
2. dify-api 1.11.2

Describe the bug
Environment:

• Deployment: Kubernetes (K8s) cluster
• Network: Plugin service port forwarded via SLB (Server Load Balancer)
• Replicas: 1 pod (works) / multiple pods (issue occurs)
• Dify-plugin-daemon Version: Version after v0.5.2 (problematic); v0.4.2 (works fine)
• Code Change: No code modifications made between versions

Description
I have identified a potential bug related to plugin debugging in a Kubernetes cluster deployment with SLB port forwarding.
The issue manifests as follows:

• Single-pod scenario: The plugin service runs with only one pod, and there is no "plugin not found" error; all requests work as expected.
• Cluster scenario (multiple pods): When the plugin service is scaled to multiple pods in K8s (with SLB forwarding the plugin installation port), most requests return a "plugin not found" error. However, a small number of requests will occasionally succeed.

Suspected Root Cause

• My hypothesis is that during the plugin registration process, the plugin establishes a TCP connection with a specific pod in the K8s cluster. The connection information (or related registration metadata) is not synchronized across other pods in the cluster. Since SLB distributes requests across all pods, only the pod that holds the TCP connection can handle the plugin request successfully, while other pods fail to recognize the plugin and throw errors.

Key Observation

• This issue does NOT exist in version v0.4.2. When I roll back the plugin service to v0.4.2 (with exactly the same K8s/SLB configuration and no code changes), the "plugin not found" error disappears completely in both single-pod and multi-pod cluster modes.
• Expected Behavior
• Plugin registration and connection information should be synchronized across all pods in the K8s cluster, ensuring consistent plugin availability for all requests regardless of which pod the SLB routes the traffic to.

Steps to Reproduce

• Deploy dify-plugin-daemon (version > v0.4.2) to a K8s cluster with multiple replicas (≥2 pods).
• Configure SLB to forward the plugin installation port to the K8s service of the plugin daemon.
• Send consecutive requests to invoke/install the plugin via the SLB endpoint.
• Observe that most requests fail with "plugin not found", while a few requests succeed randomly (likely routed to the pod with the established TCP connection).
• Roll back the deployment to v0.4.2 (same K8s/SLB configuration, no code changes).
• Verify that all requests succeed consistently in both single-pod and multi-pod modes.

Additional Context

• The plugin service is exposed via a K8s Service (ClusterIP/NodePort) and fronted by SLB for external access.
• No network policies are blocking pod-to-pod communication within the cluster.
• SLB uses standard round-robin load balancing (no sticky session/configured affinity).

Originally created by @gaoding-hailang on GitHub (Jan 23, 2026). **Self Checks** To make sure we get to you in time, please check the following :) - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify-plugin-daemon/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，否则会被关闭。谢谢！:) - [ ] "Please do not modify this template :) and fill in all the required fields." **Versions** 1. dify-plugin-daemon 0.5.2 2. dify-api 1.11.2 **Describe the bug** **Environment:** - Deployment: Kubernetes (K8s) cluster - Network: Plugin service port forwarded via SLB (Server Load Balancer) - Replicas: 1 pod (works) / multiple pods (issue occurs) - Dify-plugin-daemon Version: Version after v0.5.2 (problematic); v0.4.2 (works fine) - Code Change: No code modifications made between versions **Description** I have identified a potential bug related to plugin debugging in a Kubernetes cluster deployment with SLB port forwarding. The issue manifests as follows: - Single-pod scenario: The plugin service runs with only one pod, and there is no "plugin not found" error; all requests work as expected. - Cluster scenario (multiple pods): When the plugin service is scaled to multiple pods in K8s (with SLB forwarding the plugin installation port), most requests return a "plugin not found" error. However, a small number of requests will occasionally succeed. **Suspected Root Cause** - My hypothesis is that during the plugin registration process, the plugin establishes a TCP connection with a specific pod in the K8s cluster. The connection information (or related registration metadata) is not synchronized across other pods in the cluster. Since SLB distributes requests across all pods, only the pod that holds the TCP connection can handle the plugin request successfully, while other pods fail to recognize the plugin and throw errors. **Key Observation** - This issue does NOT exist in version v0.4.2. When I roll back the plugin service to v0.4.2 (with exactly the same K8s/SLB configuration and no code changes), the "plugin not found" error disappears completely in both single-pod and multi-pod cluster modes. - Expected Behavior - Plugin registration and connection information should be synchronized across all pods in the K8s cluster, ensuring consistent plugin availability for all requests regardless of which pod the SLB routes the traffic to. **Steps to Reproduce** - Deploy dify-plugin-daemon (version > v0.4.2) to a K8s cluster with multiple replicas (≥2 pods). - Configure SLB to forward the plugin installation port to the K8s service of the plugin daemon. - Send consecutive requests to invoke/install the plugin via the SLB endpoint. - Observe that most requests fail with "plugin not found", while a few requests succeed randomly (likely routed to the pod with the established TCP connection). - Roll back the deployment to v0.4.2 (same K8s/SLB configuration, no code changes). - Verify that all requests succeed consistently in both single-pod and multi-pod modes. **Additional Context** - The plugin service is exposed via a K8s Service (ClusterIP/NodePort) and fronted by SLB for external access. - No network policies are blocking pod-to-pod communication within the cluster. - SLB uses standard round-robin load balancing (no sticky session/configured affinity).

yindo added the plugin-daemonbug labels 2026-02-16 01:15:03 -05:00

yindo commented 2026-02-16 01:15:03 -05:00

Author

Owner

Copy Link

Copy Source

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

This error is a known regression in dify-plugin-daemon after v0.5.2 when running multiple pods in Kubernetes. The root cause is that plugin runtime registration and state are stored in local (in-memory) maps per pod, not shared across the cluster. So, when SLB routes requests to different pods, only the pod that registered the plugin runtime can serve requests; others return "plugin not found" errors. This behavior changed after v0.4.2, which did not enforce strict version matching or trigger the same race conditions in environment setup source.

The open-source version does not synchronize plugin runtime state between pods, and there is no built-in distributed locking or coordination for plugin environment initialization. Sharing persistent storage (PVC) helps avoid plugin data loss after restarts, but does not solve runtime registration sync source. The ControlPanel watchdog logic in v0.5.1+ can cause concurrent environment initialization across pods, leading to race conditions and unpredictable failures source.

Workarounds: run a single replica, avoid sharing plugin working directories (but share plugin/package directories), or implement a custom distributed lock (e.g., Redis) for environment setup. If you need true multi-pod support, a distributed locking mechanism is required to serialize plugin environment initialization source. Also, ensure plugin configuration version numbers match exactly in v0.5.2+ source.

There is no official solution for multi-pod runtime registration sync in the open-source codebase as of the latest versions. The enterprise edition may have features to address this, but for open-source, these architectural limitations remain source.

To reply, just mention @dosu.

---

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

  

@dosubot[bot] commented on GitHub (Jan 23, 2026): <!-- Answer --> This error is a known regression in dify-plugin-daemon after v0.5.2 when running multiple pods in Kubernetes. The root cause is that plugin runtime registration and state are stored in local (in-memory) maps per pod, not shared across the cluster. So, when SLB routes requests to different pods, only the pod that registered the plugin runtime can serve requests; others return "plugin not found" errors. This behavior changed after v0.4.2, which did not enforce strict version matching or trigger the same race conditions in environment setup [source](https://github.com/langgenius/dify-plugin-daemon/issues/574). The open-source version does not synchronize plugin runtime state between pods, and there is no built-in distributed locking or coordination for plugin environment initialization. Sharing persistent storage (PVC) helps avoid plugin data loss after restarts, but does not solve runtime registration sync [source](https://github.com/langgenius/dify-plugin-daemon/issues/424). The ControlPanel watchdog logic in v0.5.1+ can cause concurrent environment initialization across pods, leading to race conditions and unpredictable failures [source](https://github.com/langgenius/dify-plugin-daemon/issues/541). Workarounds: run a single replica, avoid sharing plugin working directories (but share plugin/package directories), or implement a custom distributed lock (e.g., Redis) for environment setup. If you need true multi-pod support, a distributed locking mechanism is required to serialize plugin environment initialization [source](https://github.com/langgenius/dify-plugin-daemon/issues/541). Also, ensure plugin configuration version numbers match exactly in v0.5.2+ [source](https://github.com/langgenius/dify-plugin-daemon/issues/574). There is no official solution for multi-pod runtime registration sync in the open-source codebase as of the latest versions. The enterprise edition may have features to address this, but for open-source, these architectural limitations remain [source](https://github.com/langgenius/dify-plugin-daemon/issues/541). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- ^{How did I do? [Good](https://app.dosu.dev/response-feedback/cc404219-38d7-4c60-bb7c-e7cc5d347bef?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/cc404219-38d7-4c60-bb7c-e7cc5d347bef?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/cc404219-38d7-4c60-bb7c-e7cc5d347bef?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/cc404219-38d7-4c60-bb7c-e7cc5d347bef?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/cc404219-38d7-4c60-bb7c-e7cc5d347bef?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/cc404219-38d7-4c60-bb7c-e7cc5d347bef?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/cc404219-38d7-4c60-bb7c-e7cc5d347bef?feedback_type=other)} [](https://cursor.com/link/prompt?text=This%20error%20is%20a%20known%20regression%20in%20dify-plugin-daemon%20after%20v0.5.2%20when%20running%20multiple%20pods%20in%20Kubernetes.%20The%20root%20cause%20is%20that%20plugin%20runtime%20registration%20and%20state%20are%20stored%20in%20local%20%28in-memory%29%20maps%20per%20pod%2C%20not%20shared%20across%20the%20cluster.%20So%2C%20when%20SLB%20routes%20requests%20to%20different%20pods%2C%20only%20the%20pod%20that%20registered%20the%20plugin%20runtime%20can%20serve%20requests%3B%20others%20return%20%22plugin%20not%20found%22%20errors.%20This%20behavior%20changed%20after%20v0.4.2%2C%20which%20did%20not%20enforce%20strict%20version%20matching%20or%20trigger%20the%20same%20race%20conditions%20in%20environment%20setup%20%5Bsource%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/issues/574%29.%0A%0AThe%20open-source%20version%20does%20not%20synchronize%20plugin%20runtime%20state%20between%20pods%2C%20and%20there%20is%20no%20built-in%20distributed%20locking%20or%20coordination%20for%20plugin%20environment%20initialization.%20Sharing%20persistent%20storage%20%28PVC%29%20helps%20avoid%20plugin%20data%20loss%20after%20restarts%2C%20but%20does%20not%20solve%20runtime%20registration%20sync%20%5Bsource%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/issues/424%29.%20The%20ControlPanel%20watchdog%20logic%20in%20v0.5.1%2B%20can%20cause%20concurrent%20environment%20initialization%20across%20pods%2C%20leading%20to%20race%20conditions%20and%20unpredictable%20failures%20%5Bsource%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/issues/541%29.%0A%0AWorkarounds%3A%20run%20a%20single%20replica%2C%20avoid%20sharing%20plugin%20working%20directories%20%28but%20share%20plugin/package%20directories%29%2C%20or%20implement%20a%20custom%20distributed%20lock%20%28e.g.%2C%20Redis%29%20for%20environment%20setup.%20If%20you%20need%20true%20multi-pod%20support%2C%20a%20distributed%20locking%20mechanism%20is%20required%20to%20serialize%20plugin%20environment%20initialization%20%5Bsource%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/issues/541%29.%20Also%2C%20ensure%20plugin%20configuration%20version%20numbers%20match%20exactly%20in%20v0.5.2%2B%20%5Bsource%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/issues/574%29.%0A%0AThere%20is%20no%20official%20solution%20for%20multi-pod%20runtime%20registration%20sync%20in%20the%20open-source%20codebase%20as%20of%20the%20latest%20versions.%20The%20enterprise%20edition%20may%20have%20features%20to%20address%20this%2C%20but%20for%20open-source%2C%20these%20architectural%20limitations%20remain%20%5Bsource%5D%28https%3A//github.com/langgenius/dify-plugin-daemon/issues/541%29.)&nbsp;[](https://go.dosu.dev/discord-bot)&nbsp;[](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify-plugin-daemon/issues/577)

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

Author

Owner

Copy Link

Copy Source

@fatelei commented on GitHub (Jan 28, 2026):

Self Checks

To make sure we get to you in time, please check the following :)

• 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，否则会被关闭。谢谢！:)[ ] "Please do not modify this template :) and fill in all the required fields."

Versions

1. dify-plugin-daemon 0.5.2
2. dify-api 1.11.2

Describe the bug Environment:

• Deployment: Kubernetes (K8s) cluster
• Network: Plugin service port forwarded via SLB (Server Load Balancer)
• Replicas: 1 pod (works) / multiple pods (issue occurs)
• Dify-plugin-daemon Version: Version after v0.5.2 (problematic); v0.4.2 (works fine)
• Code Change: No code modifications made between versions

Description I have identified a potential bug related to plugin debugging in a Kubernetes cluster deployment with SLB port forwarding. The issue manifests as follows:

• Single-pod scenario: The plugin service runs with only one pod, and there is no "plugin not found" error; all requests work as expected.
• Cluster scenario (multiple pods): When the plugin service is scaled to multiple pods in K8s (with SLB forwarding the plugin installation port), most requests return a "plugin not found" error. However, a small number of requests will occasionally succeed.

Suspected Root Cause

• My hypothesis is that during the plugin registration process, the plugin establishes a TCP connection with a specific pod in the K8s cluster. The connection information (or related registration metadata) is not synchronized across other pods in the cluster. Since SLB distributes requests across all pods, only the pod that holds the TCP connection can handle the plugin request successfully, while other pods fail to recognize the plugin and throw errors.

Key Observation

• This issue does NOT exist in version v0.4.2. When I roll back the plugin service to v0.4.2 (with exactly the same K8s/SLB configuration and no code changes), the "plugin not found" error disappears completely in both single-pod and multi-pod cluster modes.
• Expected Behavior
• Plugin registration and connection information should be synchronized across all pods in the K8s cluster, ensuring consistent plugin availability for all requests regardless of which pod the SLB routes the traffic to.

Steps to Reproduce

• Deploy dify-plugin-daemon (version > v0.4.2) to a K8s cluster with multiple replicas (≥2 pods).
• Configure SLB to forward the plugin installation port to the K8s service of the plugin daemon.
• Send consecutive requests to invoke/install the plugin via the SLB endpoint.
• Observe that most requests fail with "plugin not found", while a few requests succeed randomly (likely routed to the pod with the established TCP connection).
• Roll back the deployment to v0.4.2 (same K8s/SLB configuration, no code changes).
• Verify that all requests succeed consistently in both single-pod and multi-pod modes.

Additional Context

• The plugin service is exposed via a K8s Service (ClusterIP/NodePort) and fronted by SLB for external access.
• No network policies are blocking pod-to-pod communication within the cluster.
• SLB uses standard round-robin load balancing (no sticky session/configured affinity).

because the dify-plugin-daemon origin code is not support replica, you can change the code, add app.pluginManager.AddClusterTunnel(app.cluster), you need implement the method AddClusterTunnel, after modify the code, different k8s pod will sync the python package install info, so it will not lead the error: no avaiable node

@fatelei commented on GitHub (Jan 28, 2026): > **Self Checks** > > To make sure we get to you in time, please check the following :) > > * [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify-plugin-daemon/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，否则会被关闭。谢谢！:)[ ] "Please do not modify this template :) and fill in all the required fields." > > **Versions** > > 1. dify-plugin-daemon 0.5.2 > 2. dify-api 1.11.2 > > **Describe the bug** **Environment:** > > * Deployment: Kubernetes (K8s) cluster > * Network: Plugin service port forwarded via SLB (Server Load Balancer) > * Replicas: 1 pod (works) / multiple pods (issue occurs) > * Dify-plugin-daemon Version: Version after v0.5.2 (problematic); v0.4.2 (works fine) > * Code Change: No code modifications made between versions > > **Description** I have identified a potential bug related to plugin debugging in a Kubernetes cluster deployment with SLB port forwarding. The issue manifests as follows: > > * Single-pod scenario: The plugin service runs with only one pod, and there is no "plugin not found" error; all requests work as expected. > * Cluster scenario (multiple pods): When the plugin service is scaled to multiple pods in K8s (with SLB forwarding the plugin installation port), most requests return a "plugin not found" error. However, a small number of requests will occasionally succeed. > > **Suspected Root Cause** > > * My hypothesis is that during the plugin registration process, the plugin establishes a TCP connection with a specific pod in the K8s cluster. The connection information (or related registration metadata) is not synchronized across other pods in the cluster. Since SLB distributes requests across all pods, only the pod that holds the TCP connection can handle the plugin request successfully, while other pods fail to recognize the plugin and throw errors. > > **Key Observation** > > * This issue does NOT exist in version v0.4.2. When I roll back the plugin service to v0.4.2 (with exactly the same K8s/SLB configuration and no code changes), the "plugin not found" error disappears completely in both single-pod and multi-pod cluster modes. > * Expected Behavior > * Plugin registration and connection information should be synchronized across all pods in the K8s cluster, ensuring consistent plugin availability for all requests regardless of which pod the SLB routes the traffic to. > > **Steps to Reproduce** > > * Deploy dify-plugin-daemon (version > v0.4.2) to a K8s cluster with multiple replicas (≥2 pods). > * Configure SLB to forward the plugin installation port to the K8s service of the plugin daemon. > * Send consecutive requests to invoke/install the plugin via the SLB endpoint. > * Observe that most requests fail with "plugin not found", while a few requests succeed randomly (likely routed to the pod with the established TCP connection). > * Roll back the deployment to v0.4.2 (same K8s/SLB configuration, no code changes). > * Verify that all requests succeed consistently in both single-pod and multi-pod modes. > > **Additional Context** > > * The plugin service is exposed via a K8s Service (ClusterIP/NodePort) and fronted by SLB for external access. > * No network policies are blocking pod-to-pod communication within the cluster. > * SLB uses standard round-robin load balancing (no sticky session/configured affinity). because the dify-plugin-daemon origin code is not support replica, you can change the code, add `app.pluginManager.AddClusterTunnel(app.cluster)`, you need implement the method `AddClusterTunnel`, after modify the code, different k8s pod will sync the python package install info, so it will not lead the error: no avaiable node

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

Author

Owner

Copy Link

Copy Source

@fatelei commented on GitHub (Jan 28, 2026):

if you do want modify the code, you need use serverless to deploy plugin

@fatelei commented on GitHub (Jan 28, 2026): if you do want modify the code, you need use serverless to deploy plugin

yindo referenced this issue 2026-02-16 01:15:49 -05:00

[PR #232] [MERGED] chore: add checkout step in publish-cli workflow (#229) #388

Sign in to join this conversation.

No Branch/Tag Specified

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

0.6.5

0.6.4

0.6.3

0.6.2

0.6.1

0.6.0

0.5.9

0.5.8

0.5.7

0.5.6

0.5.5

0.5.4

0.5.3

0.5.2

0.5.1

0.5.0

0.4.1

0.4.0

0.3.3

0.3.2

0.3.1

0.3.0

0.3.0b1

0.2.0

0.1.3

0.1.2

0.1.1

0.1.0

0.0.10

0.0.9

0.0.8

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

0.0.1

0.0.1-beta.23

0.0.1-beta.22

0.0.1-beta.21

0.0.1-beta.20

0.0.1-beta.19

0.0.1-beta.18

0.0.1-beta.17

0.0.1-beta.16

0.0.1-beta.15

0.0.1-beta.14

0.0.1-beta.13

0.0.1-beta.12

0.0.1-beta.11

0.0.1-beta.10

0.0.1-beta.9

0.0.1-beta.8

0.0.1-beta.7

0.0.1-beta.6

0.0.1-beta.5

0.0.1-beta.4

0.0.1-beta.3

0.0.1-beta.2

0.0.1-beta.1

Labels

Clear labels

Windows

bug

cmd

documentation

enhancement

go

good first issue

plugin-daemon

pull-request

Mirrored from GitHub Pull Request

question

No Label bug plugin-daemon

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

yindo

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: langgenius/dify-plugin-daemon#232