When I use the iteration node in a Dify workflow, it runs normally if I choose serial mode. However, when I use parallel mode, it returns error: timeout error: sohnal: killed, and neither the input nor the output is displayed.

[jiangpeng663]

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.

When I use the iteration node in a Dify workflow, it runs normally if I choose serial mode. However, when I use parallel mode, it returns error: timeout error: sohnal: killed, and neither the input nor the output is displayed.

2. Additional context or comments

No response

[dosubot[bot]]

This is the same issue that was reported and resolved earlier in this very discussion thread by @jiangpeng663. The timeout error: signal: killed in parallel mode happens because parallel execution sends multiple simultaneous requests to the plugin daemon, which can exhaust timeouts and resources that are sufficient for serial execution but not for concurrent load.

Here's what to configure in your docker-compose.yaml under the plugin_daemon service [1]:

plugin_daemon:
  environment:
    PLUGIN_MAX_EXECUTION_TIMEOUT: 1200
    PLUGIN_DAEMON_TIMEOUT: 1200
    PYTHON_ENV_INIT_TIMEOUT: 320

You should also increase the sandbox worker capacity in volumes/sandbox/conf/config.yaml [2]:

max_workers: 8
worker_timeout: 15

After making changes, restart with docker compose down && docker compose up -d.

If the issue persists, you could also try reducing the parallelism in your iteration node or splitting the workload into smaller batches.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[dosubot[bot]]

You're correct — these are different issues. The plugin installation timeout is about dependency downloads during plugin setup, while your issue is about the iteration node failing at runtime when executing in parallel mode.

The parallel iteration timeout error: signal: killed happens because parallel mode sends multiple simultaneous requests to the plugin daemon and sandbox workers concurrently. The default resource limits and timeouts are tuned for sequential workloads, so under parallel load they get overwhelmed and kill the processes [1].

Here's what to tune for your specific issue:

1. Increase plugin execution timeouts in docker-compose.yaml [2]:

plugin_daemon:
  environment:
    PLUGIN_MAX_EXECUTION_TIMEOUT: 1200
    PLUGIN_DAEMON_TIMEOUT: 1200

2. Increase sandbox worker capacity in volumes/sandbox/conf/config.yaml — the defaults (max_workers: 4, worker_timeout: 5s) are too low for parallel workloads [3]:

max_workers: 8
worker_timeout: 15

3. Optionally allocate more memory to the plugin daemon [3]:

plugin_daemon:
  mem_limit: 2g

After changes, restart with docker compose down && docker compose up -d.

There are also a few known limitations with parallel iteration mode to be aware of [4]:

• Maximum 10 concurrent iterations
• Avoid placing Direct Answer, Variable Assignment, or Tool nodes directly inside iteration nodes during parallel execution, as these can cause errors
• If any single iteration thread hangs (e.g., from an LLM or HTTP call), there's no per-thread timeout — only the global workflow timeout applies

If tuning doesn't resolve it, reducing the parallel_nums setting on the iteration node or splitting your data into smaller batches can help.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[jiangpeng663]

When one Dify workflow calls another workflow, how can I make the logs also show the logs of the called workflow? Is that possible, or do I have to merge them into a single workflow?@dosu.

[dosubot[bot]]

The behavior depends on where the child workflow is invoked:

• At the root level of the parent workflow (not inside a loop/iteration): the child workflow's execution logs do appear in its own run history, so you can view them separately [1].
• Inside an iteration or loop node: there's a known observability gap where the child workflow executes successfully but no logs or traces are generated in its history panel [1]. This is caused by trace ID and context propagation being lost inside the iterator's scope [2].

In either case, the parent workflow's log will show the Workflow Tool node's input/output, but won't inline the full detailed step-by-step trace of the child workflow — you'd need to check the child workflow's own run history for that.

A fix for the missing logs inside iteration nodes was proposed in PR #29199 [2]. You don't need to merge everything into a single workflow, but if you're calling workflows inside loops and need visibility, that's currently a workaround until the trace propagation fix is fully available in your version.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[jiangpeng663]

One more question: In a Dify workflow, how can I configure one Start node to connect to three LLM nodes at the same time, so that those three LLM nodes run in parallel instead of sequentially?@dosu.

[dosubot[bot]]

You can do this natively — just draw three separate edges from the Start node to each of the three LLM nodes in the workflow editor. No special parallel node is needed [1].

However, there's an important catch: by default, the branches will still execute sequentially even though they look parallel in the UI. This is because the default worker pool setting is min_workers=1 [2].

To enable actual parallel execution, add these to your .env file [3]:

GRAPH_ENGINE_MIN_WORKERS=4
GRAPH_ENGINE_MAX_WORKERS=10

Both variables must be set — setting only MAX_WORKERS isn't enough [3]. Then restart your containers with docker compose down && docker compose up -d.

One limitation to be aware of: downstream nodes cannot have multiple incoming edges from different parallel branches [4]. So if you need to merge the outputs of all three LLM nodes, you may need to route each to its own intermediate node first, then converge.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[HamzaSwitch]

This is a known issue in Dify v1.13.x when using parallel mode in iteration nodes. The root cause is that the graphon package (which handles workflow execution) spawns worker threads via ThreadPoolExecutor, but Flask's application context doesn't propagate to those threads.

When a node inside the iteration tries to access the database or model configurations (e.g. loading LLM provider settings), it needs current_app from Flask — but the worker thread doesn't have it, so the operation either times out or crashes with "Working outside of application context."

Workaround for now: Switch to sequential mode for iteration nodes that involve LLM calls or database access.

Tracking: This is tracked in issue #34511. The root cause was introduced when the graph engine was externalized into the graphon package (PR #34209), which lost the thread-local context isolation fixes that were present in the in-tree version (PRs #31410 and #30607).

A proper fix needs to happen in the graphon package to propagate Flask app context into the ThreadPoolExecutor worker threads.

[jiangpeng663]

thank you very much

[PcChip]

FYI this is also happening to me in dify 1.16.1 - when I use parallel/threaded mode, it sometimes errors out with a timeout