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

Excessive Whitespace in Streaming Response Buffer for Gemini Flash 2.5 in Loop Nodes #17899

New Issue
Closed
opened 2026-02-21 19:41:07 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 19:41:07 -05:00
Owner
Copy Link
Copy Source

Originally created by @TuringCorp-net on GitHub (Sep 22, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.8.1

Cloud or Self Hosted

Cloud

Steps to reproduce

Problem Description

When using Gemini Flash 2.5 in loop nodes, the streaming response accumulates excessive whitespace characters in the output buffer, sometimes reaching up to 80,000 characters. This occurs due to the high-speed nature of Gemini Flash 2.5 triggering rate limiting, which causes the model to send heartbeat packets to maintain the connection. These heartbeat packets are incorrectly processed as content and accumulated in the response buffer.

✔️ Expected Behavior

Root Cause Analysis

The issue stems from the streaming response processing mechanism in Dify's plugin model client implementation. When Gemini Flash 2.5 encounters rate limiting due to its fast response speed, it sends heartbeat packets (typically empty or whitespace-only content) to keep the connection alive. However, the current implementation doesn't filter out these heartbeat packets and treats them as legitimate content chunks.

Problem Code Locations

    Plugin Model Client - model.py :

    • The invoke_llm method processes all streaming chunks without filtering heartbeat packets

    Base Plugin Client - base.py :

    • The _stream_request method processes all lines starting with "data:" without content validation
    • The _request_with_plugin_daemon_response_stream method only checks for empty data but doesn't validate content quality

    LLM Node Processing - node.py :

    • The handle_invoke_result method accumulates all text content without filtering whitespace-only chunks

Technical Details

The llm_entities.py defines the LLMResultChunk structure with a delta field containing LLMResultChunkDelta , which includes the message content. The current implementation doesn't validate whether the message content is meaningful or just heartbeat data.

❌ Actual Behavior

No response

Originally created by @TuringCorp-net on GitHub (Sep 22, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [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, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.8.1 ### Cloud or Self Hosted Cloud ### Steps to reproduce ### Problem Description When using Gemini Flash 2.5 in loop nodes, the streaming response accumulates excessive whitespace characters in the output buffer, sometimes reaching up to 80,000 characters. This occurs due to the high-speed nature of Gemini Flash 2.5 triggering rate limiting, which causes the model to send heartbeat packets to maintain the connection. These heartbeat packets are incorrectly processed as content and accumulated in the response buffer. ### ✔️ Expected Behavior ### Root Cause Analysis The issue stems from the streaming response processing mechanism in Dify's plugin model client implementation. When Gemini Flash 2.5 encounters rate limiting due to its fast response speed, it sends heartbeat packets (typically empty or whitespace-only content) to keep the connection alive. However, the current implementation doesn't filter out these heartbeat packets and treats them as legitimate content chunks. ### Problem Code Locations 1. 1. Plugin Model Client - `model.py` : - The `invoke_llm` method processes all streaming chunks without filtering heartbeat packets 2. 2. Base Plugin Client - `base.py` : - The `_stream_request` method processes all lines starting with "data:" without content validation - The `_request_with_plugin_daemon_response_stream` method only checks for empty data but doesn't validate content quality 3. 3. LLM Node Processing - `node.py` : - The `handle_invoke_result` method accumulates all text content without filtering whitespace-only chunks ### Technical Details The `llm_entities.py` defines the LLMResultChunk structure with a delta field containing LLMResultChunkDelta , which includes the message content. The current implementation doesn't validate whether the message content is meaningful or just heartbeat data. ### ❌ Actual Behavior _No response_
yindo closed this issue 2026-02-21 19:41:07 -05:00
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
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#17899
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?