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

Execution issue with code nodes subsequent to LLM node #19948

New Issue
Closed
opened 2026-02-21 20:05:05 -05:00 by yindo · 4 comments
yindo commented 2026-02-21 20:05:05 -05:00
Owner
Copy Link
Copy Source

Originally created by @taoXIANGWEI on GitHub (Oct 27, 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.9.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

When executing a workflow that includes an LLM node, either within the workspace or by invoking the API.

✔️ Expected Behavior

The workflow is running normally.

❌ Actual Behavior

I encountered an issue while executing a workflow in version 1.9.2. After the LLM node runs, the subsequent code nodes fail to execute properly. Once the LLM node completes, it directly throws an "unknown" error, and the workflow stops running. However, executing the nodes individually works correctly. I'm not sure if all nodes following the LLM node will encounter this issue, but currently, the problem occurs with code nodes (Python). Below is the API error message:

2025-10-27 06:21:19.711 ERROR [GraphDispatcher] [dispatcher.py:123] - Dispatcher error
Traceback (most recent call last):
File "/app/api/core/workflow/graph_engine/orchestration/dispatcher.py", line 105, in _dispatcher_loop
self._event_handler.dispatch(event)
File "/app/api/core/workflow/graph_engine/event_management/event_handlers.py", line 99, in dispatch
return self._dispatch(event)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/functools.py", line 949, in _method
return method.get(obj, cls)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/core/workflow/graph_engine/event_management/event_handlers.py", line 234, in _
result = self._error_handler.handle_node_failure(event)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/core/workflow/graph_engine/error_handler.py", line 65, in handle_node_failure
node = self._graph.nodes[event.node_id]
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
KeyError: 'unknown'
2025-10-27 06:21:19.810 ERROR [Thread-194 (_generate_worker)] [workflow_entry.py:111] - Unknown Error when workflow entry running
Traceback (most recent call last):
File "/app/api/core/workflow/workflow_entry.py", line 107, in run
yield from generator
File "/app/api/core/workflow/graph_engine/graph_engine.py", line 268, in run
raise self._graph_execution.error
File "/app/api/core/workflow/graph_engine/orchestration/dispatcher.py", line 105, in _dispatcher_loop
self._event_handler.dispatch(event)
File "/app/api/core/workflow/graph_engine/event_management/event_handlers.py", line 99, in dispatch
return self._dispatch(event)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/functools.py", line 949, in _method
return method.get(obj, cls)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/core/workflow/graph_engine/event_management/event_handlers.py", line 234, in _
result = self._error_handler.handle_node_failure(event)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/core/workflow/graph_engine/error_handler.py", line 65, in handle_node_failure
node = self._graph.nodes[event.node_id]
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
KeyError: 'unknown'

Originally created by @taoXIANGWEI on GitHub (Oct 27, 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.9.2 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce When executing a workflow that includes an LLM node, either within the workspace or by invoking the API. ### ✔️ Expected Behavior The workflow is running normally. ### ❌ Actual Behavior I encountered an issue while executing a workflow in version 1.9.2. After the LLM node runs, the subsequent code nodes fail to execute properly. Once the LLM node completes, it directly throws an "unknown" error, and the workflow stops running. However, executing the nodes individually works correctly. I'm not sure if all nodes following the LLM node will encounter this issue, but currently, the problem occurs with code nodes (Python). Below is the API error message: 2025-10-27 06:21:19.711 ERROR [GraphDispatcher] [dispatcher.py:123] - Dispatcher error Traceback (most recent call last): File "/app/api/core/workflow/graph_engine/orchestration/dispatcher.py", line 105, in _dispatcher_loop self._event_handler.dispatch(event) File "/app/api/core/workflow/graph_engine/event_management/event_handlers.py", line 99, in dispatch return self._dispatch(event) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/functools.py", line 949, in _method return method.__get__(obj, cls)(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/workflow/graph_engine/event_management/event_handlers.py", line 234, in _ result = self._error_handler.handle_node_failure(event) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/workflow/graph_engine/error_handler.py", line 65, in handle_node_failure node = self._graph.nodes[event.node_id] ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^ KeyError: 'unknown' 2025-10-27 06:21:19.810 ERROR [Thread-194 (_generate_worker)] [workflow_entry.py:111] - Unknown Error when workflow entry running Traceback (most recent call last): File "/app/api/core/workflow/workflow_entry.py", line 107, in run yield from generator File "/app/api/core/workflow/graph_engine/graph_engine.py", line 268, in run raise self._graph_execution.error File "/app/api/core/workflow/graph_engine/orchestration/dispatcher.py", line 105, in _dispatcher_loop self._event_handler.dispatch(event) File "/app/api/core/workflow/graph_engine/event_management/event_handlers.py", line 99, in dispatch return self._dispatch(event) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/functools.py", line 949, in _method return method.__get__(obj, cls)(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/workflow/graph_engine/event_management/event_handlers.py", line 234, in _ result = self._error_handler.handle_node_failure(event) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/workflow/graph_engine/error_handler.py", line 65, in handle_node_failure node = self._graph.nodes[event.node_id] ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^ KeyError: 'unknown'
yindo added the 🐞 bug label 2026-02-21 20:05:05 -05:00
yindo closed this issue 2026-02-21 20:05:05 -05:00
yindo commented 2026-02-21 20:05:05 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 27, 2025):

This error is caused by PostgreSQL terminating a connection due to an idle-in-transaction timeout, which leaves the workflow or graph state inconsistent. When this happens, Dify's event system can generate events with invalid node IDs like 'unknown', leading to a KeyError in the error handler when it tries to access self._graph.nodes[event.node_id] with a key that doesn't exist. The error handler currently doesn't gracefully handle missing or invalid node IDs, so the crash propagates and breaks workflow execution. This is a known issue in Dify 1.9.2 self-hosted Docker setups, especially in workflows involving LLM nodes followed by code nodes. You can find more details and user reports in this issue.

Recommended actions:

  • Audit your workflow and agent node code to ensure all database queries and updates are wrapped in context-managed sessions (e.g., with Session(db.engine, expire_on_commit=False) as session:) for each operation. Avoid sharing db.session across threads or keeping it open across multiple loop iterations.
  • Lower the SQLALCHEMY_POOL_SIZE setting if you suspect pool exhaustion.
  • As a temporary workaround, you can increase the PostgreSQL idle_in_transaction_session_timeout value, but this only masks the issue and is not recommended for production.
  • Upgrading to a newer Dify version may help, as recent fixes refactored database access to always use context-managed sessions, preventing idle-in-transaction timeouts and improving workflow stability.

For a more robust solution, consider adding better guarding or logging to the error handler's node access in your codebase to surface the root cause and prevent fatal crashes when node IDs are missing or invalid.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Oct 27, 2025): <!-- Answer --> This error is caused by PostgreSQL terminating a connection due to an idle-in-transaction timeout, which leaves the workflow or graph state inconsistent. When this happens, Dify's event system can generate events with invalid node IDs like `'unknown'`, leading to a `KeyError` in the error handler when it tries to access `self._graph.nodes[event.node_id]` with a key that doesn't exist. The error handler currently doesn't gracefully handle missing or invalid node IDs, so the crash propagates and breaks workflow execution. This is a known issue in Dify 1.9.2 self-hosted Docker setups, especially in workflows involving LLM nodes followed by code nodes. You can find more details and user reports in [this issue](https://github.com/langgenius/dify/issues/27320). **Recommended actions:** - Audit your workflow and agent node code to ensure all database queries and updates are wrapped in context-managed sessions (e.g., `with Session(db.engine, expire_on_commit=False) as session:`) for each operation. Avoid sharing `db.session` across threads or keeping it open across multiple loop iterations. - Lower the `SQLALCHEMY_POOL_SIZE` setting if you suspect pool exhaustion. - As a temporary workaround, you can increase the PostgreSQL `idle_in_transaction_session_timeout` value, but this only masks the issue and is not recommended for production. - Upgrading to a newer Dify version may help, as recent fixes refactored database access to always use context-managed sessions, preventing idle-in-transaction timeouts and improving workflow stability. For a more robust solution, consider adding better guarding or logging to the error handler's node access in your codebase to surface the root cause and prevent fatal crashes when node IDs are missing or invalid. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/087d7016-ea3b-4ed6-9590-4bc0437bdfff?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/087d7016-ea3b-4ed6-9590-4bc0437bdfff?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/087d7016-ea3b-4ed6-9590-4bc0437bdfff?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/087d7016-ea3b-4ed6-9590-4bc0437bdfff?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/087d7016-ea3b-4ed6-9590-4bc0437bdfff?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/087d7016-ea3b-4ed6-9590-4bc0437bdfff?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/087d7016-ea3b-4ed6-9590-4bc0437bdfff?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/27492)
yindo commented 2026-02-21 20:05:05 -05:00
Author
Owner
Copy Link
Copy Source

@taoXIANGWEI commented on GitHub (Oct 27, 2025):

I applied the recommendation from issue #27320 by adjusting the configuration to POSTGRES_IDLE_IN_TRANSACTION_SESSION_TIMEOUT: -600000, but this modification prevented the dify-db-1 container from starting.

@taoXIANGWEI commented on GitHub (Oct 27, 2025): I applied the recommendation from issue #27320 by adjusting the configuration to POSTGRES_IDLE_IN_TRANSACTION_SESSION_TIMEOUT: -600000, but this modification prevented the dify-db-1 container from starting.
yindo commented 2026-02-21 20:05:05 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 27, 2025):

The dify-db-1 container failed to start because PostgreSQL does not accept negative values for idle_in_transaction_session_timeout—only non-negative integers are valid. Setting POSTGRES_IDLE_IN_TRANSACTION_SESSION_TIMEOUT to -600000 causes a startup error. To avoid this, use 0 (which disables the timeout) or a positive value in milliseconds. The latest Dify Docker setup now defaults this parameter to 0 to prevent premature termination of long-running workflows, which is a safe and recommended setting for most use cases. See the merged PR for details: chore: disable postgres timeouts for docker workflows.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Oct 27, 2025): <!-- Answer --> The dify-db-1 container failed to start because PostgreSQL does not accept negative values for idle_in_transaction_session_timeout—only non-negative integers are valid. Setting POSTGRES_IDLE_IN_TRANSACTION_SESSION_TIMEOUT to -600000 causes a startup error. To avoid this, use 0 (which disables the timeout) or a positive value in milliseconds. The latest Dify Docker setup now defaults this parameter to 0 to prevent premature termination of long-running workflows, which is a safe and recommended setting for most use cases. See the merged PR for details: [chore: disable postgres timeouts for docker workflows](https://github.com/langgenius/dify/pull/27397). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/a21e4dbd-af86-41cb-b11a-abe1c8479726?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/a21e4dbd-af86-41cb-b11a-abe1c8479726?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/a21e4dbd-af86-41cb-b11a-abe1c8479726?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/a21e4dbd-af86-41cb-b11a-abe1c8479726?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/a21e4dbd-af86-41cb-b11a-abe1c8479726?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/a21e4dbd-af86-41cb-b11a-abe1c8479726?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/a21e4dbd-af86-41cb-b11a-abe1c8479726?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/27492)
yindo commented 2026-02-21 20:05:06 -05:00
Author
Owner
Copy Link
Copy Source

@taoXIANGWEI commented on GitHub (Oct 27, 2025):

will the it shuld be POSTGRES_IDLE_IN_TRANSACTION_SESSION_TIMEOUT=600000

@taoXIANGWEI commented on GitHub (Oct 27, 2025): will the it shuld be POSTGRES_IDLE_IN_TRANSACTION_SESSION_TIMEOUT=600000
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 🐞 bug
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#19948
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?