[Bug]: workflows.errors.WorkflowRuntimeError: Error in step 'run_agent_step': 'NoneType' object has no attribute 'automatic_function_calling_history'

[rogerbarretocode]

Bug Description

Hi , i am usiing agent workflows which was running fine all this while but since today i get this error :

i tried updating google gen ai and llamindex libraries but issue persists .

please suggest a fix

Version

0.12.43

Steps to Reproduce

run agent workflow

Relevant Logs/Tracbacks

Traceback (most recent call last):
  File "C:\Users\HP\anaconda3\envs\googleadsrecsys\lib\asyncio\events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "C:\Users\HP\anaconda3\envs\googleadsrecsys\lib\site-packages\llama_index_instrumentation\dispatcher.py", line 290, in handle_future_result
    raise exception
  File "C:\Users\HP\Desktop\ducima roger work\google recommender system\newest.py", line 1232, in run_workflow
    final_result = await handler
  File "C:\Users\HP\anaconda3\envs\googleadsrecsys\lib\site-packages\workflows\workflow.py", line 416, in _run_workflow
    raise exception_raised
  File "C:\Users\HP\anaconda3\envs\googleadsrecsys\lib\site-packages\workflows\context\context.py", line 637, in _step_worker
    raise WorkflowRuntimeError(
workflows.errors.WorkflowRuntimeError: Error in step 'run_agent_step': 'NoneType' object has no attribute 'automatic_function_calling_history'

[dosubot]

This error is likely caused by a recent change in LlamaIndex 0.12.43, where the agent workflow implementation was refactored—specifically, the BaseWorkflowAgent is now a workflow itself rather than using a mixin. This change may have affected how the agent context (which holds the automatic_function_calling_history attribute) is initialized, leading to situations where it is None and causing the error you see when running agent workflows. There are no official workarounds or patches documented yet, but the root cause appears to be improper context initialization after the refactor see details and here.

If you need an immediate workaround, you could try reverting to a previous version (such as 0.12.42) where your workflow was working, or review your workflow setup to ensure the agent context is being properly initialized before running steps that access automatic_function_calling_history. If you have custom workflow code, double-check any overrides or customizations that might skip or alter context creation.

Let me know if you want help pinpointing where to check in your code or if you have more details about your workflow setup!

To reply, just mention @dosu.

---

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

[rogerbarretocode]

@dosu i get this error for 0.12.36 too

[dosubot]

This error isn't caused by a change in LlamaIndex core code in either 0.12.36 or 0.12.43. It's likely coming from an upstream dependency or integration—most likely the version of the workflows package or a related agent integration—where the context object isn't being initialized as expected, so the attribute is missing.

Check the versions of your workflows and related packages to make sure they're compatible with your LlamaIndex version. Also, review any custom workflow code or integrations that might expect or set automatic_function_calling_history. If you can, try running a minimal agent workflow in your environment to see if the error still appears—if it does, it's almost certainly an environment or dependency issue, not your code or LlamaIndex itself.

If you can share your environment details (like versions of workflows, llama-index, and any agent integrations) or any custom workflow code, I can help you dig deeper.

References:

• Recent agent workflow refactor and context handling
• Notes on context and attribute initialization

To reply, just mention @dosu.

---

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

[rogerbarretocode]

@dosu

llama-cloud==0.1.19
llama-cloud-services==0.6.22
llama-index==0.12.36
llama-index-agent-openai==0.4.7
llama-index-cli==0.4.1
llama-index-core==0.12.36
llama-index-embeddings-openai==0.3.1
llama-index-indices-managed-llama-cloud==0.6.11
llama-index-instrumentation==0.2.0
llama-index-llms-gemini==0.4.14
llama-index-llms-google-genai==0.2.1
llama-index-llms-openai==0.3.40
llama-index-multi-modal-llms-openai==0.4.3
llama-index-program-openai==0.3.1
llama-index-question-gen-openai==0.3.0
llama-index-readers-file==0.4.7
llama-index-readers-llama-parse==0.4.0
llama-index-workflows==0.2.2
llama-parse==0.6.22

google-ai-generativelanguage==0.6.15
google-api-core==2.25.0rc1
google-api-python-client==2.169.0
google-auth==2.40.1
google-auth-httplib2==0.2.0
google-genai==1.15.0
google-generativeai==0.8.5

[dosubot]

Your error is almost certainly caused by a version mismatch or incompatibility between your llama-index-* packages and the external workflows/context packages, not by a bug in LlamaIndex core. The attribute automatic_function_calling_history is not defined or managed by LlamaIndex itself—it’s expected to be present in the context object provided by the upstream workflows package or your integration code. If that context isn’t initialized correctly, you’ll get this error.

To fix this, make sure all your llama-index-* packages (including core, workflows, agent, and instrumentation) are on the exact same minor version, and that your workflows package (if installed separately) is compatible with your llama-index-workflows version. Even a small mismatch can cause missing attributes or context errors like this example.

If you have any custom code or integrations that reference automatic_function_calling_history, double-check that the context is being set up before it’s accessed. If possible, try running a minimal, official agent workflow example in a clean environment with only the required llama-index-* and workflows packages to isolate the problem.

Recent refactors (see PR #19052 and PR #19134) changed how context is handled, so version alignment is even more important now. Let me know if you want help narrowing down which package might be out of sync!

To reply, just mention @dosu.

---

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

[rogerbarretocode]

@dosu okay i fixed the dependacy issue but now i get this error . the workflow still ends abruptly Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x000001BD85F049A0>
Unclosed connector
connections: ['deque([(<aiohttp.client_proto.ResponseHandler object at 0x000001BDFF7CD300>, 73002.671)])']
connector: <aiohttp.connector.TCPConnector object at 0x000001BD85F04880>

Workflow completed successfully!

Final Result

[dosubot]

The "Unclosed client session" and "Unclosed connector" warnings from aiohttp mean that somewhere in your stack, an async HTTP session wasn't properly closed before your script exited. These are not fatal errors, but they do indicate a resource leak that can cause problems in long-running or production workloads (source, source).

LlamaIndex itself doesn't directly manage aiohttp sessions—these are usually created by third-party integrations (like LLM SDKs, readers, or custom code). Most integrations in LlamaIndex use async with aiohttp.ClientSession() to ensure proper cleanup, but if any integration or user code creates a session without closing it (for example, not using async with or not calling await session.close()), you'll see these warnings (source).

To fix this, audit your stack for any custom or third-party code that creates aiohttp.ClientSession objects and make sure they're always used in an async with block or explicitly closed. For example:

async with aiohttp.ClientSession() as session:
    # your async HTTP calls here

or, if you must manage the session manually:

session = aiohttp.ClientSession()
try:
    # your async HTTP calls here
finally:
    await session.close()

If you can't immediately fix the warning and your workflow is short-lived, it's generally safe to ignore, but it's best practice to clean it up for production. If you want help pinpointing the source, share details about the LLMs, readers, or custom integrations you're using.

More info: example issue, best practices.

To reply, just mention @dosu.

---

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

[rogerbarretocode]

@dosu my workflow is ending abruptly . this same code used to work perfactly 2 days ago

[dosubot]

A recent change in LlamaIndex introduced a default iteration limit (often 10 or 20) for agent workflows—if your workflow hits this, it will end early, which could explain the abrupt stop if your tasks need more steps than the new default allows. Check your logs for a message like "Reached max iterations." If that's the case, set a higher limit when initializing your agent, for example:

agent = ReActAgent(..., max_iterations=50)

or pass max_iterations=50 via kwargs if your agent class supports it.

For the "Unclosed client session" warning: this comes from an async HTTP session (aiohttp) not being closed, usually in a third-party LLM or integration. LlamaIndex integrations use async with aiohttp.ClientSession() to manage this, but if you or a dependency create sessions manually, make sure to close them with await session.close() or use an async with block. This warning is not fatal, but it's best to clean it up for production reference.

If you don't see a "Reached max iterations" error and the workflow just stops, please share any error or log message right before the abrupt end—this will help pinpoint if it's an iteration limit, a resource cleanup issue, or something else. Also, let me know if any package or environment changes happened in the last two days.

To reply, just mention @dosu.

---

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

[rogerbarretocode]

@dosu i checked docs for baseagent anf fucntionagent . it doesnt have any max_iterations parameter

[dosubot]

You're correct—BaseAgent and FunctionAgent do not have a max_iterations parameter, and this is by design. The iteration limit (max_iterations) is only available in ReActAgent and similar agents, where it's enforced in the agent's step loop. For BaseAgent and FunctionAgent, there is currently no built-in way to set or control an iteration limit, and this feature has been acknowledged as missing for workflow-based agents—it may be added in a future update (reference). If you need iteration control, you would need to implement it in your own workflow logic or switch to an agent type that supports it.

To reply, just mention @dosu.

---

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

[rogerbarretocode]

@dosu then why is my workflow ending abruptly ?

[dosubot]

There are a few likely reasons your workflow is ending abruptly, especially given recent changes in LlamaIndex and your environment:

1. If a workflow step emits a StopEvent (intentionally or due to a logic bug), the workflow will end immediately—even if other steps remain. This can happen if a tool call is misinterpreted as a final answer, or if the event flow is not set up as expected docs.
2. Recent updates require all agent memory and context operations to be fully async. If your code or any integration isn't updated to use await with memory/context methods, steps can fail silently or terminate early without a clear error PR #19032.
3. If an exception is raised in a step or during async resource cleanup (like closing an aiohttp session), but isn't caught or logged, the workflow can end with no visible error. This is especially common if using custom integrations or third-party LLMs docs.
4. There are known issues with context and event handling in agent workflows, especially after recent refactors. If the context is misconfigured or missing expected attributes, the workflow may terminate early or skip steps issue.

To debug: enable verbose logging, wrap your workflow steps in try/except blocks to catch silent exceptions, and check for any logic that could emit a StopEvent too early. Also, try running a minimal, official agent workflow example in your environment—if that works, the issue is likely in your workflow logic or integration code.

If you can share any log output or error message right before the abrupt end, I can help pinpoint the cause more precisely.

To reply, just mention @dosu.

---

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