fix: preserve LiteLLM text with tool calls

[asim48-ctrl]

Summary

• preserve LiteLLM assistant text content when tool calls are present
• avoid AttributeError when LiteLLM omits reasoning_content on a delta/message
• add focused regression coverage for text+tool-call and missing-reasoning cases

Fixes #1448.

Verification

• uv run --no-sync ruff check beeai_framework/adapters/litellm/chat.py tests/backend/providers/test_litellm_chat.py
• uv run --no-sync ruff format beeai_framework/adapters/litellm/chat.py tests/backend/providers/test_litellm_chat.py --check
• uv run --no-sync pytest tests/backend/providers/test_litellm_chat.py -q
• git diff --check

[gemini-code-assist]

Code Review

This pull request refactors the _transform_output method in the LiteLLM chat adapter to improve readability and ensure that both text content and tool calls are correctly captured in the output. It also introduces unit tests to verify these transformations. Review feedback suggests using an explicit "is not None" check for text content to avoid skipping empty strings and recommends using a generator expression within content.extend() for improved memory efficiency.

[gemini-code-assist]

The current check if text: will evaluate to False for an empty string "". This means if update.content is an empty string, no MessageTextContent will be created. The previous implementation effectively preserved empty strings. To maintain this behavior and only skip None values, it's safer to use if text is not None:. This ensures that an explicit empty string from the model is preserved as a text content part.

Suggested change

	if text:
	if text is not None:

[gemini-code-assist]

For better memory efficiency and conciseness, you can use a generator expression directly within content.extend() instead of creating a temporary list with a list comprehension.

                content.extend(
                    MessageToolCallContent(
                        id=call.id or "",
                        tool_name=call.function.name or "",
                        args=call.function.arguments,
                    )
                    for call in tool_calls
                )

[Tomas2D]

I would say that this is breaking change. Can the bug be fixed without merging it together?

[asim48-ctrl]

Thanks, agreed. I pushed a follow-up that no longer merges text and tool calls into the same AssistantMessage.

The updated shape preserves LiteLLM text as a separate output chunk when tool calls are also present, while keeping the tool-call message shape separate. It still fixes the missing reasoning_content AttributeError path.

Re-verified locally:

• uv run --no-sync ruff check beeai_framework/adapters/litellm/chat.py tests/backend/providers/test_litellm_chat.py
• uv run --no-sync ruff format beeai_framework/adapters/litellm/chat.py tests/backend/providers/test_litellm_chat.py --check
• uv run --no-sync pytest tests/backend/providers/test_litellm_chat.py -q
• git diff --check

[Tomas2D]

What is the difference after your changes?

[asim48-ctrl]

The updated version avoids the breaking shape I had in the first pass.

Before this PR, when LiteLLM returned both content and tool_calls, BeeAI only emitted the tool-call message and dropped the text content.

After the latest changes:

• text-only responses still produce one text AssistantMessage
• tool-call-only responses still produce one tool-call AssistantMessage
• text + tool-call responses produce two output items: first the text AssistantMessage, then the existing tool-call AssistantMessage shape
• missing reasoning_content no longer raises AttributeError

So the tool-call message shape is kept separate; the only behavioral addition is preserving text that LiteLLM already returned instead of discarding it.