alfin06/swegent-issues-filtered huggingface dataset:
[Bug]: CallbackManager not applied to default embed_model in VectorStoreIndex.from_documents

### Bug Description

When creating a `VectorStoreIndex` using `from_documents`, a provided `callback_manager` is not applied to the embedding model if the `embed_model` argument is omitted. This prevents callbacks, such as `TokenCountingHandler`, from tracking embedding token usage when relying on the global `Settings.embed_model`.

Note: A Pull Request addressing this issue has been submitted #19335 

### Version

0.12.47

### Steps to Reproduce

The following code demonstrates that embedding token counts are not recorded when relying on the default embed_model.

```python
from llama_index.core import (
    VectorStoreIndex,
    SimpleDirectoryReader,
    Settings,
)

from llama_index.core.callbacks import CallbackManager, TokenCountingHandler

from llama_index.embeddings.openai import OpenAIEmbedding

token_counter = TokenCountingHandler()
callback_manager = CallbackManager([token_counter])

Settings.embed_model = OpenAIEmbedding(model="text-embedding-3-small")
documents = SimpleDirectoryReader("./data").load_data()

token_counter.reset_counts()
index = VectorStoreIndex.from_documents(
    documents,
    callback_manager=callback_manager
)

print(f"Embedding tokens used: {token_counter.total_embedding_token_count}")
assert token_counter.total_embedding_token_count == 0, "Bug confirmed: Embedding tokens were not counted."
print("Bug confirmed: Token counter was not triggered for embedding.\n")


token_counter.reset_counts()
index_fixed = VectorStoreIndex.from_documents(
    documents,
    embed_model=Settings.embed_model, # Explicitly pass the model
    callback_manager=callback_manager
)

print(f"Embedding tokens used: {token_counter.total_embedding_token_count}")
assert token_counter.total_embedding_token_count > 0, "Workaround failed."
print("Workaround successful: Token counter was triggered for embedding.")
```

### Relevant Logs/Tracbacks

```shell

```

Labels: bug, triage
State: closed
[BUG] `kickoff` hangs when LLM call fails

### Description

`kickoff` hangs when LLM call fails

### Steps to Reproduce

Minmum example to reproduce the issue

```python
import os
from crewai import Agent, Crew, Task


# Enforce a request to the OpenAI API to fail
os.environ["OPENAI_API_KEY"] = "sk-fake"

simple_agent_1 = Agent(
    role="City Selection Expert",
    goal="Select the best city based on weather, season, and prices",
    backstory="An expert in analyzing travel data to pick ideal destinations",
    tools=[],
    llm="gpt-4",
)


task_1 = Task(
    description=("Analyze and select the best city for the trip"),
    agent=simple_agent_1,
    expected_output="Detailed report on the chosen city",
)


crew = Crew(agents=[simple_agent_1], tasks=[task_1])
print(crew.kickoff())
```

### Expected behavior

No hang

### Screenshots/Code snippets

See steps to reproduce

### Operating System

Ubuntu 20.04

### Python Version

3.10

### crewAI Version

0.98.0

### crewAI Tools Version

???

### Virtual Environment

Venv

### Evidence

```
LiteLLM.Info: If you need to debug this error, use `litellm.set_verbose=True'.

ERROR:root:LiteLLM call failed: litellm.AuthenticationError: AuthenticationError: OpenAIException - Error code: 401 - {'error': {'message': 'Incorrect API key provided: sk-fake. You can find your API key at https://platform.openai.com/account/api-keys.', 'type': 'invalid_request_error', 'param': None, 'code': 'invalid_api_key'}}


LiteLLM.Info: If you need to debug this error, use `litellm.set_verbose=True'.

ERROR:root:LiteLLM call failed: litellm.AuthenticationError: AuthenticationError: OpenAIException - Error code: 401 - {'error': {'message': 'Incorrect API key provided: sk-fake. You can find your API key at https://platform.openai.com/account/api-keys.', 'type': 'invalid_request_error', 'param': None, 'code': 'invalid_api_key'}}
```

### Possible Solution

See `steps to reproduce`

### Additional context

N/A

Labels: bug
State: closed
[Bug]: `MockLLM.stream_complete` raises error on empty prompt when `max_tokens=None`

### Bug Description

When calling `MockLLM.stream_complete("")` with `max_tokens=None`, the system attempts to construct a `LLMCompletionEndEvent` using a `None` response, which results in a `pydantic ValidationError`. However, passing an empty string "" to CompletionResponse is valid and expected behavior. The constructor accepts empty content without raising any errors:
```python
from llama_index.core.base.llms.types import CompletionResponse

response = CompletionResponse(text="", additional_kwargs={})
```

I think this issue is maybe caused by the same type-checking behavior as [Issue #19290](https://github.com/jerryjliu/llama_index/issues/19290), where empty strings (`""`) were treated as falsy and misinterpreted as `None`. But this specific instance was not fixed by [PR #19302](https://github.com/jerryjliu/llama_index/pull/19302), and still causes crashes at runtime.


### Version

llama-index-core==0.12.47

### Steps to Reproduce

```python
from llama_index.core.llms import MockLLM

llm = MockLLM(max_tokens=None)
response = llm.stream_complete("")
result = [chunk for chunk in response]

```

### Relevant Logs/Tracbacks

```shell
pydantic_core._pydantic_core.ValidationError: 1 validation error for LLMCompletionEndEvent
response
  Input should be a valid dictionary or instance of CompletionResponse [type=model_type, input_value=None, input_type=NoneType]
```

Labels: bug, P2
State: closed
[Bug]: Race condition in SQLAlchemyChatStore

### Bug Description

When using the `Memory` component, which utilizes `SQLAlchemyChatStore`, calling `memory.aput()` in rapid succession causes messages to be inserted out of order.

My guess as to the cause of the issue:
In `llama-index-core/llama_index/core/storage/chat_store/sql.py`, in `add_message()` and `add_messages()`, `time.time()` is used to generate the timestamp for the message, which only provides a second-level timestamp. Even though messages are ordered by ID as a secondary column, the IDs may not be perfectly in order.

A possible fix:
1. Change the type of the `timestamp` column to `BigInteger`
2. Use `time.time_ns()` to get a higher level of precision
3. Optionally, when adding multiple messages at the same time in `add_messages()`, add `i` to the timestamp.

### Version

0.12.48

### Steps to Reproduce

This is not an easily reproducible bug. It happens every once in a while using PostgreSQL.


Labels: bug, triage
State: closed
[Bug]: ReActAgent returns the raw output when the output parser raises an error instead of retrying

### Bug Description

Sometimes, it happens that the LLM makes a mistake when answering in the format required by the `ReActAgent`. When it occurs, the `ReActOutputParser` raises a `ValueError` describing the formatting problem. This error is caught by the `ReActAgent` in the following way by the `take_step` method:

```python
try:
    reasoning_step = output_parser.parse(message_content, is_streaming=False)
except ValueError as e:
    error_msg = f"Error: Could not parse output. Please follow the thought-action-input format. Try again. Details: {e!s}"
    await memory.aput(last_chat_response.message)
    await memory.aput(ChatMessage(role="user", content=error_msg))

    raw = (
        last_chat_response.raw.model_dump()
        if isinstance(last_chat_response.raw, BaseModel)
        else last_chat_response.raw
    )
    return AgentOutput(
        response=last_chat_response.message,
        tool_calls=[],
        raw=raw,
        current_agent_name=self.name,
    )
```

While a new user message is added to the memory to instruct the LLM to reply with the expected format, an `AgentOutput` object is still returned with the raw LLM output (thought, action, action input and answer included) instead of recalling the LLM.

### Version

0.12.48

### Steps to Reproduce

The following script reproduces the problem with a mock output formatter:

```python
import asyncio

from llama_index.core.agent.react.types import ResponseReasoningStep, BaseReasoningStep
from llama_index.core.agent.workflow import ReActAgent
from llama_index.core.types import BaseOutputParser
from llama_index.llms.openai import OpenAI


class MockOutputParser(BaseOutputParser):
    def parse(self, output: str, is_streaming: bool = False) -> BaseReasoningStep:
        if "hello" not in output.lower():
            raise ValueError('The answer should contain the word "hello"')

        return ResponseReasoningStep(
            thought="I am saying hello",
            response="hello",
        )


async def main():
    llm = OpenAI(model="gpt-4o")

    agent = ReActAgent(llm=llm, output_parser=MockOutputParser())

    print("The following is ok:")
    response = await agent.run(user_msg="Say hello")
    print(response)
    print()

    print("The following should not happen:")
    response = await agent.run(user_msg="Solve: 2 + 2")
    print(response)


if __name__ == "__main__":
    asyncio.run(main())
```

This produces the following outputs:

```
The following is ok:
Hello! How can I assist you today?

The following should not happen:
Thought: The current language of the user is English. I can solve this simple arithmetic problem without using any tools.
Answer: 2 + 2 equals 4.
```

### Relevant Logs/Tracbacks

```shell

```

Labels: bug, triage
State: closed
[Feature Request]: Add support for Google GenAI tools in llama_index.llms.google_genai

### Feature Description

I am requesting support for Google GenAI tools, specifically `google_search` in the `llama_index.llms.google_genai` module to enable Google Search grounding with Gemini LLM. This would allow fetching real-time web data to improve response accuracy for time-sensitive queries.

Example code:

```python
from llama_index.llms.google_genai import GoogleGenAI
from llama_index.core.llms import ChatMessage
from google.genai import types

llm = GoogleGenAI(model="gemini-2.0-flash")
grounding_tool = types.Tool(google_search=types.GoogleSearch())
resp = llm.predict_and_call(
    [grounding_tool],
    "When is the next total solar eclipse in the US?",
    error_on_no_tool_call=False,
)
print(resp)
```

Expected output:
> The next total solar eclipse in the US is August 23, 2044, visible in Montana, North Dakota, and South Dakota. A broader eclipse occurs August 12, 2045, from California to Florida.

**References:**  
- Google Gemini API Google Search: https://ai.google.dev/gemini-api/docs/google-search  
- Vertex AI Grounding: https://cloud.google.com/vertex-ai/generative-ai/docs/grounding/grounding-with-google-search


### Reason

The `GoogleGenAI` class lacks support for `google.genai.types.Tool`, causing errors like:

> AttributeError: 'Tool' object has no attribute 'metadata'

Manual search result fetching is inefficient and other tools and APIs lack native Google integration.


### Value of Feature

This feature would enhance LlamaIndex’s RAG capabilities with real-time web data, streamline development for Gemini users, and enable applications like dynamic chatbots, aligning with Google’s ecosystem.

Labels: enhancement, triage
State: closed
[Feature Request]: FunctionTool should support auto-conversion to more basic python types like date

### Feature Description

Currently
```python
    def func(date_param: datetime.date) -> str:
        return None
    func_tool = FunctionTool.from_defaults(fn=func)
    schema = func_tool.metadata.get_parameters_dict()
    print(schema)
```
outputs 
```json
{'properties': {'date_param': {'format': 'date', 'title': 'Date Param', 'type': 'string'}}, 'required': ['date_param'], 'type': 'object'}
```
which leads to the `func` being called with a `str` instead of a `date` object.
It would be great if llama-index supported conversion to more basic python types out of the box.

Expected metadata here would be
 ```json
{'properties': {'date_param': {'format': 'date', 'title': 'Date Param', 'type': 'date'}}, 'required': ['date_param'], 'type': 'object'}
```

and the function being called with the expected type of the object and llama-index handling string -> date conversion internally.


### Reason

Currently, instead of a simple function that accepts a date like 

```python
    def func(date_param: datetime.date) -> str:
        ...
```

I have to write a boilerplate wrapper function to be registered as a tool:

```python
    def func(date_param: datetime.date) -> str:
        ...
    def func_wrapper(date_param:Annotation[str, "Date in YYYY-MM-DD format"]) -> str:
        return func(datetime.datetime.strptime(date_param, '%Y-%m-%d').date())

```

### Value of Feature

Ease of use, less boilerplate glue code

Labels: enhancement, P2
State: closed
[Bug]: load_kwargs causes error from LLM response in WikipediaToolSpec.load_data

### Bug Description

The `WikipediaToolSpec.load_data` tool method accepts additional loading arguments through a `load_kwargs` parameter. However, this parameter is defined as a `**kwargs` parameter. 
When the LLM calls the tool with `load_kwargs={}`, the `load_kwargs` parameters gets `{"load_kwargs": {}}` as value, which is then unpacked to the wikipedia API call and causes an unexpected argument error.

### Version

0.12.49

### Steps to Reproduce

```python
import asyncio

from llama_index.core.agent.workflow import ReActAgent, ToolCall, AgentOutput
from llama_index.llms.openai import OpenAI
from llama_index.tools.wikipedia import WikipediaToolSpec


async def main():
    wikipedia_tool_spec = WikipediaToolSpec()

    agent = ReActAgent(tools=wikipedia_tool_spec.to_tool_list(), llm=OpenAI(model="gpt-4o"))

    handler = agent.run("Search information about cats in wikipedia")

    async for ev in handler.stream_events():
        if isinstance(ev, ToolCall) or isinstance(ev, AgentOutput):
            print(ev)

if __name__ == '__main__':
    asyncio.run(main())
```

### Relevant Logs/Tracbacks

```shell
Thought: The current language of the user is English. I need to use a tool to help me answer the question.
Action: load_data
Action Input: {"page": "Cat", "load_kwargs": {}}
tool_name='load_data' tool_kwargs={'page': 'Cat', 'load_kwargs': AttributedDict()} tool_id='5eff2633-d559-4268-bb1b-1d79a082a2a6'
Thought: It seems there was an error with the tool usage. I will try using the tool again without the 'load_kwargs' argument.
Action: load_data
Action Input: {"page": "Cat"}
tool_name='load_data' tool_kwargs={'page': 'Cat'} tool_id='ac4cc06f-de71-4ee0-8e8d-2eff63bce20b'
Thought: I can answer without using any more tools. I'll use the user's language to answer.
Answer: Cats, scientifically known as Felis catus, are small domesticated carnivorous mammals that have been companions to humans for thousands of years. They are valued for their ability to hunt vermin and their companionship. Cats have a flexible body, sharp claws, and excellent night vision, making them effective hunters. They communicate through various vocalizations and body language, and they have a strong sense of smell and hearing. Domesticated cats are found worldwide, with a significant population in Asia and the United States. They have a rich history and cultural significance in various societies, from ancient Egypt to modern times.
```

Labels: bug, triage
State: closed
[Bug]: KeyError in vector_store retriever since refactor starting in 0.12.49, persisting in 0.12.50

### Bug Description

Version 0.12.48 (prior to refactor) functions perfectly for my use case, upgrading past this version raises KeyErrors, including in 0.12.50.

Issue began with: #19382 

Possibly related, but did not fix my issue: #19445, #19448

### Version

0.12.50

### Steps to Reproduce

Example usage:

```
faiss_index = faiss.IndexFlatL2(EMBEDDING_DIM)
vector_store = FaissVectorStore(faiss_index=faiss_index)
storage_context = StorageContext.from_defaults(vector_store=vector_store)

index = VectorStoreIndex.from_documents(documents, storage_context=storage_context)
```

```
query_engine = llama_index.as_query_engine()
response = query_engine.query(user_message)
```



### Relevant Logs/Tracbacks

```shell
File "/project/main.py", line 239, in chat
    response = query_engine.query(user_message)
  File "/project/venv/lib/python3.13/site-packages/llama_index_instrumentation/dispatcher.py", line 324, in wrapper
    result = func(*args, **kwargs)
  File "/project/venv/lib/python3.13/site-packages/llama_index/core/base/base_query_engine.py", line 52, in query
    query_result = self._query(str_or_query_bundle)
  File "/project/venv/lib/python3.13/site-packages/llama_index_instrumentation/dispatcher.py", line 324, in wrapper
    result = func(*args, **kwargs)
  File "/project/venv/lib/python3.13/site-packages/llama_index/core/query_engine/retriever_query_engine.py", line 193, in _query
    nodes = self.retrieve(query_bundle)
  File "/project/venv/lib/python3.13/site-packages/llama_index/core/query_engine/retriever_query_engine.py", line 146, in retrieve
    nodes = self._retriever.retrieve(query_bundle)
  File "/project/venv/lib/python3.13/site-packages/llama_index_instrumentation/dispatcher.py", line 324, in wrapper
    result = func(*args, **kwargs)
  File "/project/venv/lib/python3.13/site-packages/llama_index/core/base/base_retriever.py", line 246, in retrieve
    nodes = self._retrieve(query_bundle)
  File "/project/venv/lib/python3.13/site-packages/llama_index_instrumentation/dispatcher.py", line 324, in wrapper
    result = func(*args, **kwargs)
  File "/project/venv/lib/python3.13/site-packages/llama_index/core/indices/vector_store/retrievers/retriever.py", line 104, in _retrieve
    return self._get_nodes_with_embeddings(query_bundle)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
  File "/project/venv/lib/python3.13/site-packages/llama_index/core/indices/vector_store/retrievers/retriever.py", line 222, in _get_nodes_with_embeddings
    query_result.nodes = self._insert_fetched_nodes_into_query_result(
                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        query_result, fetched_nodes
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/project/venv/lib/python3.13/site-packages/llama_index/core/indices/vector_store/retrievers/retriever.py", line 185, in _insert_fetched_nodes_into_query_result
    raise KeyError(
        f"Node ID {node_id_str} not found in fetched nodes. "
    )
KeyError: 'Node ID 37 not found in fetched nodes. '
```

Labels: bug, triage
State: closed
[Bug]: BM25 Retriever top_k should be less than len(nodes)

### Bug Description

When we use [BM25Retriever](https://docs.llamaindex.ai/en/stable/examples/retrievers/bm25_retriever), with some `top_k~20` value greater than `len(nodes)~1` initialized, bm25 raises this exception:

```py
File ~/llama_index/.venv/lib/python3.11/site-packages/bm25s/__init__.py:696, in BM25.retrieve(self, query_tokens, corpus, k, sorted, return_as, show_progress, leave_progress, n_threads, chunksize, backend_selection, weight_mask)
    694 num_docs = self.scores["num_docs"]
    695 if k > num_docs:
--> 696     raise ValueError(
    697         f"k of {k} is larger than the number of available scores"
    698         f", which is {num_docs} (corpus size should be larger than top-k)."
    699         f" Please set with a smaller k or increase the size of corpus."
    700     )
    701 allowed_return_as = ["tuple", "documents"]
    703 if return_as not in allowed_return_as:

ValueError: k of 20 is larger than the number of available scores, which is 1 (corpus size should be larger than top-k). Please set with a smaller k or increase the size of corpus.
```

I think other than bm25 retriever other retrievers allows more top_k than len(nodes).

It would be good if llama index can handle this scenario by only passing `k=len(nodes)` when `similarity_top_k > len(nodes)` else current scenario here:
https://github.com/run-llama/llama_index/blob/8b7f97c3116fe13643dd77de8a7018df2af23c7e/llama-index-integrations/retrievers/llama-index-retrievers-bm25/llama_index/retrievers/bm25/base.py#L188-L190

Let me know, If I can create a PR for the same

### Version

0.12.52

### Steps to Reproduce

Follow along this document: https://docs.llamaindex.ai/en/stable/examples/retrievers/bm25_retriever

Only change is file: `paul_graham_essay.txt` should be less than **512 characters** and `similarity_top_k=20`

### Relevant Logs/Tracbacks

```shell

```

Labels: bug, triage
State: closed
[Bug][MCP tools] Pydantic models and self defined types are not recognisable

### Bug Description

- source of the issue: https://github.com/run-llama/llama_index/blob/main/llama-index-integrations/tools/llama-index-tools-mcp/llama_index/tools/mcp/base.py (function `create_model_from_json_schema`).
- model used by agent: `gpt-4o`

The MCP agent is unable to recognise non-trivial parameter data types. These include pydantic models, Literals/enums, or custom defined types.


### Version

0.2.6 (lama-index-tools-mcp)

### Steps to Reproduce

Example MCP tool:
```py
from fastmcp import FastMCP

mcp_router = FastMCP(name="Main MCP")

@mcp_router.tool
def say_hello(input1: TestRecord, night: bool) -> str:
    ...
```

Example schema:
```py
from pydantic import BaseModel

class TestRecord(BaseModel):
    a: int
    b: str
```

Example usage with output log printing:
```py
from llama_mcp_adapter.adapter import McpToolSpecAdapter

async def get_tools():
    mcp_tool = McpToolSpecAdapter(client=local_client)
    tools = await mcp_tool.to_tool_list_async()
    pprint.pprint(tools[0].metadata.fn_schema.model_json_schema())
    return tools
```

### Relevant Logs/Tracbacks

Input definitions schema:
```bash
{'TestRecord': {'properties': {'a': {'title': 'A', 'type': 'integer'},
                               'b': {'title': 'B', 'type': 'string'}},
                'required': ['a', 'b'],
                'title': 'TestRecord',
                'type': 'object'}}
```

Output schema:
```bash
{'properties': {'input1': {'description': '',
                           'title': 'Input1',
                           'type': 'string'},
                'night': {'description': '',
                          'title': 'Night',
                          'type': 'boolean'}},
 'required': ['input1', 'night'],
 'title': 'say_hello_Schema',
 'type': 'object'}
```

Conversation with agent:
```
User:  What is the type of input1?
Agent:  The type of `input1` is a string. In the context provided, `input1` is a parameter that is expected to receive a string value.
```

Labels: bug, triage
State: closed
sys_invocation_state cannot be read

The `sys_invocation_state` table can no longer be read. It looks that this is a regression compared to version 1.0. I suspect that the `MultiplexedInvokerStatusReader` is shared between components w/o having properly shared state.

State: closed
[Feature Request]: gpt-5-chat-latest model is missing

### Feature Description

Hello, in ` llama-index-llms-openai/llama_index/llms/openai  /utils.py` is model gpt-5-chat-latest is missing. Can you add it, please?Thank you

### Reason

_No response_

### Value of Feature

_No response_

Labels: enhancement, triage
State: closed
[Feature Request]: Support text and query instructions in OllamaEmbedding

### Feature Description

It seems that `OllamaEmbedding` does not support custom query and text instructions. In contrast, `HuggingFaceEmbedding` provides `text_instruction` and `query_instruction` parameters, which are prepended to the payload. Could the same functionality be added to `OllamaEmbedding`? Or is there currently a way to configure it?

### Reason

_No response_

### Value of Feature

_No response_

Labels: enhancement, triage
State: closed
[Feature Request]: Add system prompt / tools caching in BedrockConverse

### Feature Description

With Bedrock, it is possible to cache the system prompt and tools: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html

LlamaIndex BedrockConverse does not support system prompt / tools caching and would benefit from this feature.

### Reason

_No response_

### Value of Feature

Prompt caching permits to reduce the number of token used and accelerate the inference with the LLM.

Labels: enhancement, P2
State: closed