Getting error sometimes when executing an agent flow
Bug Description
Get an error sometimes when executing an agent flow: Error building Component Agent: \n\nTool 'list_datasources' execution failed: cannot access local variable 'asyncio' where it is not associated with a value."
Reproduction
- Create Agent flow
- Add agent with an attached tool
- ask a question sometimes might get error Error building Component Agent: \n\nTool 'list_datasources' execution failed: cannot access local variable 'asyncio' where it is not associated with a value."
Expected behavior
To work always
Who can help?
No response
Operating System
kubernetes
Langflow Version
1.6.3
Python Version
None
Screenshot
No response
Flow File
No response
Same issue. Agent + tools gives this error 1/3 of the times it runs. Also in the middle of a session where it calls different tools during the same execution. All of a sudden the error comes and agent dies.
Version: 1.6.4 (latest)
Maybe this gives some context to the problem? Logs: [warning ] Tool 'executes_the_getactiveprojects_script' failed on attempt 1: RuntimeError - dictionary changed size during iteration [error ] Tool 'executes_the_getactiveprojects_script' execution failed: cannot access local variable 'asyncio' where it is not associated with a value
Same error when using kubernetes-mcp-server (SSE mode).
Facing the same error on all versions starting from (at least) 1.6.1 to 1.6.8. I checked briefely source code and it looks like it comes from mcp utils.py file:
https://github.com/langflow-ai/langflow/blob/5b5f727376fb4ed2e678139bff45fd54e7ff32ee/src/backend/base/langflow/base/mcp/util.py#L637
For some reason langflow creates new session in the middle of agent processing which causes "sessions" list to change while iterating over it.
Same error here (execution failed: cannot access local variable 'asyncio') trying to run an MCP Tool. Version 1.5.x used to work.
Traceback (most recent call last):
File "/root/langflow_env/lib64/python3.11/site-packages/langflow/base/mcp/util.py", line 1343, in run_tool
session = await self._get_or_create_session()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/langflow_env/lib64/python3.11/site-packages/langflow/base/mcp/util.py", line 1283, in _get_or_create_session
self.session = await session_manager.get_session(self._session_context, self._connection_params, "sse")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/langflow_env/lib64/python3.11/site-packages/langflow/base/mcp/util.py", line 617, in get_session
for session_id, session_info in sessions.items():
RuntimeError: dictionary changed size during iteration
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/root/langflow_env/lib64/python3.11/site-packages/langflow/base/mcp/util.py", line 215, in tool_coroutine
return await client.run_tool(tool_name, arguments=validated.model_dump())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/langflow_env/lib64/python3.11/site-packages/langflow/base/mcp/util.py", line 1368, in run_tool
is_timeout_error = isinstance(e, asyncio.TimeoutError | TimeoutError)
^^^^^^^
UnboundLocalError: cannot access local variable 'asyncio' where it is not associated with a value
I had the same problem when using a Java MCP server.
In case it helps, as a workaround I modified src/lfx/src/lfx/base/mcp/util.py so that asyncio is always available in the tool. The relevant (and only) commit is in my fork of 1.6.7 here and a rebuilt docker image containing only that fix here.
The analysis and suggested patch came from ChatGPT. Analysis:
- The MCP server (ThingsBoard) is Java and only returns tool metadata / schemas in JSON — it does not execute Python.
- LangFlow reads that JSON and dynamically creates Python StructuredTool objects (including both a synchronous func and an async coroutine) that call back to an MCP client (MCPStdioClient or MCPSseClient) to actually make the remote call.
- Those dynamically-created wrappers reference asyncio (e.g. asyncio.get_event_loop(), asyncio.wait_for(), asyncio.create_task()), but they may be executed in module contexts or threads where asyncio isn't bound as a global, or where closures accidentally shadow it — leading to intermittent cannot access local variable 'asyncio' where it is not associated with a value or “no current event loop” errors. The intermittent nature comes from how LangFlow compiles/caches/reuses these wrappers across different execution contexts and threads.
Suggestion: Modify the wrapper factory so the module asyncio is captured as a default argument when the wrapper is created. This avoids relying on asyncio being present as a module-level global at call time (works across threads).