[BUG] The LLM plugin does not work when there are binary files such as audio in the conversation history #41

Closed
opened 2026-02-16 00:19:18 -05:00 by yindo · 1 comment
Owner

Originally created by @QIN2DIM on GitHub (Mar 13, 2025).

How to Reproduce

Take the following minimal Chatflow as an example:

Image

https://r2-datalake.echosec.top/dify_dsl/boom.yml

  1. First Round: Upload an audio file and enter any query. The PROVIDER-1 node responds normally. No processing of the audio input is required, only its presence in the conversation history is needed.
  2. Second Round: Do not upload any file, enter any query to trigger the PROVIDER-2 LLM node. At this point, the node will remain in a RUNNING state indefinitely. In my case, PROVIDER-2 LLM connects to a locally deployed SGLang SRT via the OpenAI API Compatible plugin. While the node is "RUNNING," no token update logs appear in SGLang SRT, indicating the request is not actually sent to SGLang but instead idles in the plugin_daemon.
compose-env:
- dify_plugin_daemon: v0.0.3-local, v0.0.4-local
- dify: v1.0.1

Details

[1] Critical Bug: When this issue occurs, all models under PROVIDER-2 in the workspace are blocked. This means not only the affected chatflow but any other chatflows containing PROVIDER-2 models will fail to work.

[2] Universal Reproducibility: This issue occurs with any model plugin, not limited to the openai-api-compatible plugin demonstrated in the example. Other providers exhibit the same behavior.

[3] Key Observation: PROVIDER-1 (triggered by audio upload) outputs tokens normally. Only subsequent PROVIDER-2 nodes get stuck.

Originally created by @QIN2DIM on GitHub (Mar 13, 2025). ## How to Reproduce Take the following minimal Chatflow as an example: ![Image](https://github.com/user-attachments/assets/75e336b3-d0d8-468b-be56-29b466d80386) https://r2-datalake.echosec.top/dify_dsl/boom.yml 1. **First Round**: Upload an audio file and enter any query. The `PROVIDER-1` node responds normally. No processing of the audio input is required, only its presence in the conversation history is needed. 2. **Second Round**: Do **not** upload any file, enter any query to trigger the `PROVIDER-2` LLM node. At this point, the node will remain in a RUNNING state ~~indefinitely~~. In my case, `PROVIDER-2` LLM connects to a locally deployed `SGLang SRT` via the OpenAI API Compatible plugin. While the node is "RUNNING," no token update logs appear in `SGLang SRT`, indicating the request is **not actually sent to SGLang** but instead idles in the `plugin_daemon`. ```yaml compose-env: - dify_plugin_daemon: v0.0.3-local, v0.0.4-local - dify: v1.0.1 ``` ## Details [1] **Critical Bug**: When this issue occurs, **all models under `PROVIDER-2`** in the workspace are blocked. This means not only the affected chatflow but **any other chatflows** containing `PROVIDER-2` models will fail to work. [2] **Universal Reproducibility**: This issue occurs with **any model plugin**, not limited to the `openai-api-compatible` plugin demonstrated in the example. Other providers exhibit the same behavior. [3] **Key Observation**: `PROVIDER-1` (triggered by audio upload) outputs tokens normally. **Only subsequent `PROVIDER-2` nodes get stuck.**
yindo closed this issue 2026-02-16 00:19:18 -05:00
Author
Owner

@Yeuoly commented on GitHub (Mar 18, 2025):

Fixed in Dify 1.1.0, we have deprecated the token calculation

@Yeuoly commented on GitHub (Mar 18, 2025): Fixed in Dify 1.1.0, we have deprecated the token calculation
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify-plugin-daemon#41