Self Checks
Dify version
1.9.1
Cloud or Self Hosted
Self Hosted (Source)
Steps to reproduce
Create a workflow with an HTTP Request node.
Configure the node to send a POST request with binary body type (e.g., upload a 100MB+ MP3 file).
Trigger the workflow by uploading the large file via chat or API.
Observe the execution result.
📸 Screenshot attached: Workflow appears to complete, but logs show database storage error and UI shows “任务已完成” while backend fails silently.
[Workflow Execution Log]
- HTTP Request node starts...
- File uploaded: test.mp3 (141.09 MB)
- Node status changes to "SUCCEEDED" visually
- But database throws: "storage limit exceeded" or "value too long for type jsonb"
✔️ Expected Behavior
HTTP node should successfully execute and return response.
Binary file content should NOT be stored in process_data.
Only metadata (file size, filename, transfer method) should be logged.
Workflow should not fail due to database constraints.
❌ Actual Behavior
When uploading large binary files (>50MB), the HTTP node appears to succeed in UI (“任务已完成”), but:
The actual database insertion fails due to oversized JSONB field.
No clear error is shown to user — workflow continues silently.
Subsequent nodes may receive incomplete or corrupted context.
System performance degrades due to massive log entries.
💡 Root Cause: In core/workflow/nodes/http_request/executor.py, the to_log() method decodes binary content as UTF-8 string using .decode("utf-8", errors="replace"), which expands 100MB binary into ~1GB+ text string before storing it in process_data.
Additional Context
This issue is critical for production use cases involving:
Audio/video transcription
Document processing (PDFs, images)
File uploads via API or chat
The current behavior leads to:
Database bloat
Silent failures
Security risk (storing raw binary data in logs)
Self Checks
Dify version
1.9.1
Cloud or Self Hosted
Self Hosted (Source)
Steps to reproduce
Create a workflow with an HTTP Request node.
Configure the node to send a POST request with binary body type (e.g., upload a 100MB+ MP3 file).
Trigger the workflow by uploading the large file via chat or API.
Observe the execution result.
📸 Screenshot attached: Workflow appears to complete, but logs show database storage error and UI shows “任务已完成” while backend fails silently.
[Workflow Execution Log]
✔️ Expected Behavior
HTTP node should successfully execute and return response.
Binary file content should NOT be stored in process_data.
Only metadata (file size, filename, transfer method) should be logged.
Workflow should not fail due to database constraints.
❌ Actual Behavior
When uploading large binary files (>50MB), the HTTP node appears to succeed in UI (“任务已完成”), but:
The actual database insertion fails due to oversized JSONB field.
No clear error is shown to user — workflow continues silently.
Subsequent nodes may receive incomplete or corrupted context.
System performance degrades due to massive log entries.
💡 Root Cause: In core/workflow/nodes/http_request/executor.py, the to_log() method decodes binary content as UTF-8 string using .decode("utf-8", errors="replace"), which expands 100MB binary into ~1GB+ text string before storing it in process_data.
Additional Context
This issue is critical for production use cases involving:
Audio/video transcription
Document processing (PDFs, images)
File uploads via API or chat
The current behavior leads to:
Database bloat
Silent failures
Security risk (storing raw binary data in logs)