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

An error occurred when the agent front-end application invoked the workflow tool. #21940

New Issue
Open
opened 2026-02-21 20:14:56 -05:00 by yindo · 6 comments
yindo commented 2026-02-21 20:14:56 -05:00
Owner
Copy Link
Copy Source

Originally created by @Moiyu1998 on GitHub (Jan 27, 2026).

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

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Image Image Image

As shown in the image above, the workflow tool can be invoked normally from the testing interface, but an error occurs when the front-end application calls the tool.

✔️ Expected Behavior

The front-end application is able to invoke the workflow tool normally.

❌ Actual Behavior

No response

Originally created by @Moiyu1998 on GitHub (Jan 27, 2026). ### 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.11.4 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce <img width="1837" height="857" alt="Image" src="https://github.com/user-attachments/assets/cbdb6860-0447-4608-8bfe-bebe479477a6" /> <img width="817" height="869" alt="Image" src="https://github.com/user-attachments/assets/d954e8af-c6ef-4f56-a79d-7b33c135ac14" /> <img width="1105" height="829" alt="Image" src="https://github.com/user-attachments/assets/ee198434-ed7a-430a-8d84-20061df791d4" /> As shown in the image above, the workflow tool can be invoked normally from the testing interface, but an error occurs when the front-end application calls the tool. ### ✔️ Expected Behavior The front-end application is able to invoke the workflow tool normally. ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 20:14:56 -05:00
yindo commented 2026-02-21 20:14:56 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 27, 2026):

The error Instance <EndUser> is not bound to a Session; attribute refresh operation cannot proceed means the backend is trying to access a database object (EndUser) after its SQLAlchemy session has closed or been interrupted. This happens because the workflow tool is invoked through two different backend paths: the testing interface keeps the session alive and uses the logged-in Account, while the front-end loads EndUser in a short-lived session, closes it, and passes a detached object to the workflow generator. If the workflow generator doesn't re-query EndUser in a new session, you get this error source.

Best practices to avoid this error:
Always pass IDs (like Account or EndUser ID) between workflow nodes, agents, and tools, and re-query the object inside a fresh session before accessing its attributes. Never pass ORM objects across async boundaries or outside the session scope. If you must use an ORM object after the session is closed, re-attach it with db.session.merge(object) source.

Troubleshooting steps:

  1. Enable detailed logging: set ENABLE_REQUEST_LOGGING=True, LOG_LEVEL=DEBUG, and SQLALCHEMY_ECHO=True in your .env file, then restart your containers.
  2. Check the workflow_app_logs database table for more context about workflow execution and session errors source.
  3. Review your workflow/tool code to ensure you are not passing ORM objects between boundaries—pass only IDs and re-query as needed.

Workarounds and fixes:

  • If you are on Dify v1.11.4, the codebase already uses a session factory and improved session handling, but if the issue persists, upgrade to the latest version after v1.8.0, which includes more robust fixes for session management source.
  • As a temporary workaround, you can modify the extract_tenant_id function in api/libs/helper.py to return a static tenant ID, but this is not recommended for multi-tenant setups source.

Let me know if you need more specific code pointers or help with debugging your workflow/tool logic.

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Jan 27, 2026): <!-- Answer --> The error `Instance <EndUser> is not bound to a Session; attribute refresh operation cannot proceed` means the backend is trying to access a database object (EndUser) after its SQLAlchemy session has closed or been interrupted. This happens because the workflow tool is invoked through two different backend paths: the testing interface keeps the session alive and uses the logged-in Account, while the front-end loads EndUser in a short-lived session, closes it, and passes a detached object to the workflow generator. If the workflow generator doesn't re-query EndUser in a new session, you get this error [source](https://github.com/langgenius/dify/discussions/27832). **Best practices to avoid this error:** Always pass IDs (like Account or EndUser ID) between workflow nodes, agents, and tools, and re-query the object inside a fresh session before accessing its attributes. Never pass ORM objects across async boundaries or outside the session scope. If you must use an ORM object after the session is closed, re-attach it with `db.session.merge(object)` [source](https://github.com/langgenius/dify/discussions/27832). **Troubleshooting steps:** 1. Enable detailed logging: set `ENABLE_REQUEST_LOGGING=True`, `LOG_LEVEL=DEBUG`, and `SQLALCHEMY_ECHO=True` in your `.env` file, then restart your containers. 2. Check the `workflow_app_logs` database table for more context about workflow execution and session errors [source](https://github.com/langgenius/dify-docs/issues/529). 3. Review your workflow/tool code to ensure you are not passing ORM objects between boundaries—pass only IDs and re-query as needed. **Workarounds and fixes:** - If you are on Dify v1.11.4, the codebase already uses a session factory and improved session handling, but if the issue persists, upgrade to the latest version after v1.8.0, which includes more robust fixes for session management [source](https://github.com/langgenius/dify/discussions/27832). - As a temporary workaround, you can modify the `extract_tenant_id` function in `api/libs/helper.py` to return a static tenant ID, but this is not recommended for multi-tenant setups [source](https://github.com/langgenius/dify/issues/25412). Let me know if you need more specific code pointers or help with debugging your workflow/tool logic. <!-- 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/73fe6127-6dec-4ac8-9472-7d6ebc624c27?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/73fe6127-6dec-4ac8-9472-7d6ebc624c27?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/73fe6127-6dec-4ac8-9472-7d6ebc624c27?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/73fe6127-6dec-4ac8-9472-7d6ebc624c27?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/73fe6127-6dec-4ac8-9472-7d6ebc624c27?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/73fe6127-6dec-4ac8-9472-7d6ebc624c27?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/73fe6127-6dec-4ac8-9472-7d6ebc624c27?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20error%20%60Instance%20%3CEndUser%3E%20is%20not%20bound%20to%20a%20Session%3B%20attribute%20refresh%20operation%20cannot%20proceed%60%20means%20the%20backend%20is%20trying%20to%20access%20a%20database%20object%20%28EndUser%29%20after%20its%20SQLAlchemy%20session%20has%20closed%20or%20been%20interrupted.%20This%20happens%20because%20the%20workflow%20tool%20is%20invoked%20through%20two%20different%20backend%20paths%3A%20the%20testing%20interface%20keeps%20the%20session%20alive%20and%20uses%20the%20logged-in%20Account%2C%20while%20the%20front-end%20loads%20EndUser%20in%20a%20short-lived%20session%2C%20closes%20it%2C%20and%20passes%20a%20detached%20object%20to%20the%20workflow%20generator.%20If%20the%20workflow%20generator%20doesn%27t%20re-query%20EndUser%20in%20a%20new%20session%2C%20you%20get%20this%20error%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/discussions/27832%29.%0A%0A%2A%2ABest%20practices%20to%20avoid%20this%20error%3A%2A%2A%20%20%0AAlways%20pass%20IDs%20%28like%20Account%20or%20EndUser%20ID%29%20between%20workflow%20nodes%2C%20agents%2C%20and%20tools%2C%20and%20re-query%20the%20object%20inside%20a%20fresh%20session%20before%20accessing%20its%20attributes.%20Never%20pass%20ORM%20objects%20across%20async%20boundaries%20or%20outside%20the%20session%20scope.%20If%20you%20must%20use%20an%20ORM%20object%20after%20the%20session%20is%20closed%2C%20re-attach%20it%20with%20%60db.session.merge%28object%29%60%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/discussions/27832%29.%0A%0A%2A%2ATroubleshooting%20steps%3A%2A%2A%20%20%0A1.%20Enable%20detailed%20logging%3A%20set%20%60ENABLE_REQUEST_LOGGING%3DTrue%60%2C%20%60LOG_LEVEL%3DDEBUG%60%2C%20and%20%60SQLALCHEMY_ECHO%3DTrue%60%20in%20your%20%60.env%60%20file%2C%20then%20restart%20your%20containers.%20%20%0A2.%20Check%20the%20%60workflow_app_logs%60%20database%20table%20for%20more%20context%20about%20workflow%20execution%20and%20session%20errors%20%5Bsource%5D%28https%3A//github.com/langgenius/dify-docs/issues/529%29.%0A3.%20Review%20your%20workflow/tool%20code%20to%20ensure%20you%20are%20not%20passing%20ORM%20objects%20between%20boundaries%E2%80%94pass%20only%20IDs%20and%20re-query%20as%20needed.%0A%0A%2A%2AWorkarounds%20and%20fixes%3A%2A%2A%20%20%0A-%20If%20you%20are%20on%20Dify%20v1.11.4%2C%20the%20codebase%20already%20uses%20a%20session%20factory%20and%20improved%20session%20handling%2C%20but%20if%20the%20issue%20persists%2C%20upgrade%20to%20the%20latest%20version%20after%20v1.8.0%2C%20which%20includes%20more%20robust%20fixes%20for%20session%20management%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/discussions/27832%29.%0A-%20As%20a%20temporary%20workaround%2C%20you%20can%20modify%20the%20%60extract_tenant_id%60%20function%20in%20%60api/libs/helper.py%60%20to%20return%20a%20static%20tenant%20ID%2C%20but%20this%20is%20not%20recommended%20for%20multi-tenant%20setups%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/25412%29.%0A%0ALet%20me%20know%20if%20you%20need%20more%20specific%20code%20pointers%20or%20help%20with%20debugging%20your%20workflow/tool%20logic.)&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/31636)
yindo commented 2026-02-21 20:14:56 -05:00
Author
Owner
Copy Link
Copy Source

@Moiyu1998 commented on GitHub (Jan 27, 2026):

All other tools work correctly in both the front-end interface and the testing interface, but the workflow tool only works in the testing interface and not in the front-end interface.

@Moiyu1998 commented on GitHub (Jan 27, 2026): All other tools work correctly in both the front-end interface and the testing interface, but the workflow tool only works in the testing interface and not in the front-end interface.
yindo commented 2026-02-21 20:14:56 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 28, 2026):

This happens because the workflow tool’s front-end path loads the EndUser object in a short-lived SQLAlchemy session, then passes it to the workflow engine after the session is closed. When the workflow tries to access EndUser attributes later, you get the “not bound to a Session” error. Other tools don’t hit this because their execution is synchronous and finishes before the session closes, but the workflow tool hands off the user object to a long-running process that needs it later source.

To work around this in v1.11.4, always pass only the EndUser ID (not the ORM object) between workflow/tool boundaries, and re-query the EndUser inside a fresh session right before use in your workflow logic. This ensures the object is session-bound when accessed and avoids the error source.

A permanent fix for this was merged after v1.11.4 (PR #30913), so upgrading to a newer version will resolve the issue. If you need help with code pointers for where to re-query the user, let me know!

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Jan 28, 2026): <!-- Answer --> This happens because the workflow tool’s front-end path loads the EndUser object in a short-lived SQLAlchemy session, then passes it to the workflow engine after the session is closed. When the workflow tries to access EndUser attributes later, you get the “not bound to a Session” error. Other tools don’t hit this because their execution is synchronous and finishes before the session closes, but the workflow tool hands off the user object to a long-running process that needs it later [source](https://github.com/langgenius/dify/issues/31113). To work around this in v1.11.4, always pass only the EndUser ID (not the ORM object) between workflow/tool boundaries, and re-query the EndUser inside a fresh session right before use in your workflow logic. This ensures the object is session-bound when accessed and avoids the error [source](https://github.com/langgenius/dify/issues/31227). A permanent fix for this was merged after v1.11.4 ([PR #30913](https://github.com/langgenius/dify/pull/30913)), so upgrading to a newer version will resolve the issue. If you need help with code pointers for where to re-query the user, let me know! <!-- 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/6edd49c3-ac6d-4dac-a156-7a8f5311fde2?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/6edd49c3-ac6d-4dac-a156-7a8f5311fde2?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/6edd49c3-ac6d-4dac-a156-7a8f5311fde2?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/6edd49c3-ac6d-4dac-a156-7a8f5311fde2?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/6edd49c3-ac6d-4dac-a156-7a8f5311fde2?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/6edd49c3-ac6d-4dac-a156-7a8f5311fde2?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/6edd49c3-ac6d-4dac-a156-7a8f5311fde2?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20happens%20because%20the%20workflow%20tool%E2%80%99s%20front-end%20path%20loads%20the%20EndUser%20object%20in%20a%20short-lived%20SQLAlchemy%20session%2C%20then%20passes%20it%20to%20the%20workflow%20engine%20after%20the%20session%20is%20closed.%20When%20the%20workflow%20tries%20to%20access%20EndUser%20attributes%20later%2C%20you%20get%20the%20%E2%80%9Cnot%20bound%20to%20a%20Session%E2%80%9D%20error.%20Other%20tools%20don%E2%80%99t%20hit%20this%20because%20their%20execution%20is%20synchronous%20and%20finishes%20before%20the%20session%20closes%2C%20but%20the%20workflow%20tool%20hands%20off%20the%20user%20object%20to%20a%20long-running%20process%20that%20needs%20it%20later%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/31113%29.%0A%0ATo%20work%20around%20this%20in%20v1.11.4%2C%20always%20pass%20only%20the%20EndUser%20ID%20%28not%20the%20ORM%20object%29%20between%20workflow/tool%20boundaries%2C%20and%20re-query%20the%20EndUser%20inside%20a%20fresh%20session%20right%20before%20use%20in%20your%20workflow%20logic.%20This%20ensures%20the%20object%20is%20session-bound%20when%20accessed%20and%20avoids%20the%20error%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/31227%29.%0A%0AA%20permanent%20fix%20for%20this%20was%20merged%20after%20v1.11.4%20%28%5BPR%20%2330913%5D%28https%3A//github.com/langgenius/dify/pull/30913%29%29%2C%20so%20upgrading%20to%20a%20newer%20version%20will%20resolve%20the%20issue.%20If%20you%20need%20help%20with%20code%20pointers%20for%20where%20to%20re-query%20the%20user%2C%20let%20me%20know%21)&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/31636)
yindo commented 2026-02-21 20:14:56 -05:00
Author
Owner
Copy Link
Copy Source

@fatelei commented on GitHub (Jan 28, 2026):

this bug has been fixed in latest code, you can use main branch code

@fatelei commented on GitHub (Jan 28, 2026): this bug has been fixed in latest code, you can use main branch code
yindo commented 2026-02-21 20:14:57 -05:00
Author
Owner
Copy Link
Copy Source

@sammrai commented on GitHub (Jan 29, 2026):

+1

@sammrai commented on GitHub (Jan 29, 2026): +1
yindo commented 2026-02-21 20:14:57 -05:00
Author
Owner
Copy Link
Copy Source

@sammrai commented on GitHub (Feb 8, 2026):

+1

In my environment, updating to v1.12.0 resolved the issue.

@sammrai commented on GitHub (Feb 8, 2026): > +1 In my environment, updating to v1.12.0 resolved the issue.
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#21940
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?