execute cannot be used while an asynchronous query is underway

[sszaodian]

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 (Source)

Steps to reproduce

i send message to chatflow, chatflow no response

trace log
Traceback (most recent call last):
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context
self.dialect.do_execute(
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/default.py", line 952, in do_execute
cursor.execute(statement, parameters)
psycopg2.ProgrammingError: execute cannot be used while an asynchronous query is underway

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/app/api/controllers/web/completion.py", line 181, in post
response = AppGenerateService.generate(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/extensions/otel/decorators/base.py", line 37, in wrapper
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/app/api/services/app_generate_service.py", line 88, in generate
AdvancedChatAppGenerator().generate(
File "/app/api/core/app/apps/advanced_chat/app_generator.py", line 205, in generate
return self._generate(
^^^^^^^^^^^^^^^
File "/app/api/core/app/apps/advanced_chat/app_generator.py", line 458, in _generate
db.session.refresh(workflow)
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/orm/scoping.py", line 1750, in refresh
return self._proxied.refresh(
^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/orm/session.py", line 3154, in refresh
loading.load_on_ident(
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/orm/loading.py", line 510, in load_on_ident
return load_on_pk_identity(
^^^^^^^^^^^^^^^^^^^^
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/orm/loading.py", line 695, in load_on_pk_identity
session.execute(
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/orm/session.py", line 2351, in execute
return self._execute_internal(
^^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/orm/session.py", line 2249, in _execute_internal
result: Result[Any] = compile_state_cls.orm_execute_statement(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/orm/context.py", line 306, in orm_execute_statement
result = conn.execute(
^^^^^^^^^^^^^
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1419, in execute
return meth(
^^^^^
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/sql/elements.py", line 527, in _execute_on_connection
return connection._execute_clauseelement(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1641, in _execute_clauseelement
ret = self._execute_context(
^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1846, in _execute_context
return self._exec_single_context(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1986, in _exec_single_context
self._handle_dbapi_exception(
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 2363, in _handle_dbapi_exception
raise sqlalchemy_exception.with_traceback(exc_info[2]) from e
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context
self.dialect.do_execute(
File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/default.py", line 952, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (psycopg2.ProgrammingError) execute cannot be used while an asynchronous query is underway
[SQL: SELECT workflows.id, workflows.tenant_id, workflows.app_id, workflows.type, workflows.version, workflows.marked_name, workflows.marked_comment, workflows.graph, workflows.features, workflows.created_by, workflows.created_at, workflows.updated_by, workflows.updated_at, workflows.environment_variables, workflows.conversation_variables, workflows.rag_pipeline_variables
FROM workflows
WHERE workflows.id = %(pk_1)s::UUID]
[parameters: {'pk_1': '7095bdf3-e5d1-4356-837e-18aa67678e66'}]
(Background on this error at: https://sqlalche.me/e/20/f405)

✔️ Expected Behavior

chatflow should response

❌ Actual Behavior

no response

[dosubot]

This error happens because Dify 1.11.4 uses Flask-SQLAlchemy's db.session, which is not thread-safe and is tied to the Flask request context. In the chatflow code, a background worker thread is started for generation, but the main thread continues to use db.session to refresh objects after the thread starts. This causes concurrent access to the same session/connection, triggering the "execute cannot be used while an asynchronous query is underway" error from psycopg2 and SQLAlchemy. This is a classic concurrency/session management issue in Python web apps using SQLAlchemy and Flask with threads [details].

Recent Dify versions have fixed this by introducing a session factory and refactoring all database access to use per-thread/per-context sessions (see PR #29628, PR #30913). Each thread now creates and uses its own session, never sharing db.session or a connection across threads, and always closes sessions after use. This prevents the async/sync conflict and the error you are seeing.

To resolve this, upgrade to a version of Dify that includes these session management fixes. If you cannot upgrade, a workaround is to avoid using db.session after starting background threads, or refactor your code so that every thread or async task creates and uses its own SQLAlchemy session (using sessionmaker or scoped_session), and never shares db.session or a connection across threads [issue reference].

There is no Docker or psycopg2 configuration that can fix this; it must be addressed in the application code [SQLAlchemy docs]. For production stability, always ensure thread-local session isolation in threaded or async code paths.

To reply, just mention @dosu.

---

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

   

[crazywoola]

Hi @sszaodian, thanks for opening this issue.

Why this is being closed

This issue indicates you are running Dify from the Self Hosted (Source) deployment method.

Next steps

We do not provide technical support for starting from the source. Thank you for your understanding. We assume you have the necessary expertise to set it up independently. If you require technical support, please obtain our business license by contacting us at business@dify.ai.

If you believe this is a genuine bug that affects other deployment methods as well, please reproduce the issue using Docker or Cloud deployment and open a new issue with those details.