View logs of Dify plugin

[xiaotang-12-ops]

Self Checks

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

1. Is this request related to a challenge you're experiencing? Tell me about your story.

This is my workflow. It gets stuck at the DOC plugin I created. The error output is that a certain variable exceeds 48 characters, causing it to fail to run. I opened the workflow of the DOC plugin but found no relevant logs, which makes me unable to troubleshoot where exactly the error occurs. How can I solve this problem?

2. Additional context or comments

No response

[xiaotang-12-ops]

[dosubot[bot]]

The variable length limit error (48 or 60 characters) is enforced at the workflow node level in Dify, usually in input or variable assignment nodes, and sometimes inherited by plugin nodes. These constraints are set in the workflow's schema or backend validation logic. To troubleshoot, use the workflow editor: click on the node (such as your DOC plugin or input node) and select "Last run" to view detailed logs, including input/output data and error messages. For step-by-step debugging, use the Variable Inspector to inspect and modify variable values and rerun nodes to pinpoint where the length violation occurs [docs].

Dify does not provide plugin-specific logging or a way to increase log verbosity just for plugins. All logs are integrated into the workflow and node execution logs. If you need more detailed logs, you can increase the global logging level (e.g., DEBUG) for the Dify server or add custom logging in your plugin code.

To work around the length constraint, you can preprocess or truncate input variables before they reach the node with the limit, or adjust the schema/constants in your workflow or plugin code if you control them. If the limit is enforced by the plugin or workflow schema, you’ll need to update those definitions in your codebase.

To reply, just mention @dosu.

---

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

[xiaotang-12-ops]

The variable length limit error (48 or 60 characters) is enforced at the workflow node level in Dify, usually in input or variable assignment nodes, and sometimes inherited by plugin nodes. These constraints are set in the workflow's schema or backend validation logic. To troubleshoot, use the workflow editor: click on the node (such as your DOC plugin or input node) and select "Last run" to view detailed logs, including input/output data and error messages. For step-by-step debugging, use the Variable Inspector to inspect and modify variable values and rerun nodes to pinpoint where the length violation occurs [docs].

Dify does not provide plugin-specific logging or a way to increase log verbosity just for plugins. All logs are integrated into the workflow and node execution logs. If you need more detailed logs, you can increase the global logging level (e.g., DEBUG) for the Dify server or add custom logging in your plugin code.

To work around the length constraint, you can preprocess or truncate input variables before they reach the node with the limit, or adjust the schema/constants in your workflow or plugin code if you control them. If the limit is enforced by the plugin or workflow schema, you’ll need to update those definitions in your codebase.

To reply, just mention @dosu.

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

I think I have explained it very clearly. There are no relevant logs in the DOC workflow, and there are no logs transmitted to the DOC workflow at all. The chatflow that calls the DOC workflow keeps showing as running, and it is also impossible to view the logs. As shown in the figure.

[dosubot[bot]]

When a DOC plugin node is stuck in "running" with no logs, it's usually because the plugin didn't signal completion or error back to the workflow engine, or an error (like a variable length violation) wasn't properly caught and reported. This can happen if the plugin crashes, hangs, or returns output that doesn't match the expected schema—preventing the workflow from yielding a completion event and thus blocking logs from being displayed in the UI (example).

To troubleshoot:

1. Check your DOC plugin code to ensure all errors are caught and that it always returns a result or raises an exception—never hang or exit silently. If you use custom output, make sure it matches the required schema for downstream nodes.
2. Enable debug logging by setting LOG_LEVEL=DEBUG and (optionally) LOG_FILE in your .env file. For Docker, check /app/logs/server.log or use docker-compose logs to see backend errors (reference).
3. If your plugin processes large inputs or outputs, increase PLUGIN_STDIO_BUFFER_SIZE and PLUGIN_STDIO_MAX_BUFFER_SIZE in your Docker .env to avoid log/output truncation (reference).
4. Make sure you’re running the latest Dify and plugin versions—recent updates fixed log display and agent log identifier issues that could affect log visibility (reference).
5. Try isolating the DOC plugin in a minimal workflow to see if the issue persists. If it works, the problem may be with variable assignment or downstream nodes.

If the node still gets stuck, focus on error handling and output schema in your plugin, and check backend logs for any uncaught exceptions or timeouts. This should help you pinpoint why logs aren't appearing and the node isn't completing.

To reply, just mention @dosu.

---

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