fix(llm): prevent orphaned tool_calls and missing type field in continue-gen path

[lobstersyrup]

Fix 1: Missing type field in continue-gen tool calls

Problem: _call_llm_for_continue_gen passes raw Tool TypedDicts directly to _call_llm without formatting first. The Tool TypedDict has no type field — it gets added by format_tools(). When a response hits finish_reason: length and enters the continue-generation path, the unformatted tools cause:

openai.BadRequestError: Error code: 400 - tools[0]: missing field `type`

Fix: Added self.format_tools(tools) in _call_llm_for_continue_gen in both openai_llm.py and deepseek_llm.py.

Fix 2: Orphaned tool_calls causing "insufficient tool messages" error (fixes #909)

Problem: When finish_reason: length fires with tool_calls present in the truncated response, _continue_generate and _stream_continue_generate append the partial assistant message (containing tool_calls) to the message history, then immediately call the LLM for continuation without executing the tools. The resulting messages list has assistant tool_calls but no corresponding tool responses, causing:

openai.BadRequestError: insufficient tool messages following tool_calls message

This causes sub-agents (e.g., Reporter) to crash after 3 retries, leading to infinite re-spawn loops.

Fix: Return early when tool_calls are present, letting the normal step() tool-execution loop handle the truncated message:

• _continue_generate (line 526): if new_message.tool_calls: return new_message
• _stream_continue_generate (line 346): add not message.tool_calls and guard before the finish_reason continuation check

Testing

Tested both fixes with deepseek-v4-pro on the deep_research/v2 pipeline. Without the fixes, the pipeline reliably hits both errors. With both fixes applied, the pipeline completes without errors.

[gemini-code-assist]

Code Review

This pull request updates the _call_llm_for_continue_gen method in both DeepSeekLLM and OpenAILLM to ensure tools are properly formatted before the LLM call. While the tool formatting fix is correct, the implementation in DeepSeekLLM contains several critical issues: a logic error where the stop sequences are lost because list.append() returns None, a potential AttributeError due to a naming mismatch in the message formatting call, and a missing update to the API call counter.

[gemini-code-assist]

While adding self.format_tools(tools) correctly addresses the tool formatting issue, this method contains several other critical bugs that will likely prevent it from functioning as intended:

1. AttributeError: Line 37 calls self.format_input_message(messages), but the base class method is named _format_input_message (with a leading underscore). This will cause a runtime error.
2. Logic Error: Line 38 incorrectly sets the stop variable to None because list.append() operates in-place and returns None. Consequently, the stop=stop argument passed on line 40 will always be None, effectively losing all intended stop sequences.
3. Redundancy: The _call_llm method already handles message formatting internally (via _format_input_message), making the call on line 37 unnecessary even if the name were correct.
4. Missing State Update: Unlike the base class implementation in OpenAI, this override fails to increment messages[-1].api_calls, which may affect tracking or logic dependent on the number of API attempts.

I recommend refactoring this method to address these issues alongside the tool formatting fix.

[lobstersyrup]

Thanks for the thorough review. All four findings are technically correct, but they identify pre-existing bugs in a class that's dead code:

The DeepSeek class isn't registered in model_mapping.py's all_services_mapping, so LLM.from_config() never instantiates it. Its __init__ requires deepseek_base_url and deepseek_api_key config keys that no standard config provides — users can't reach it through the normal config path. It has no unit tests and isn't referenced by any example or project config in the repo.

Our one-line change (adding self.format_tools(tools)) is consistent with the existing pattern in OpenAI._call_llm_for_continue_gen and is harmless belt-and-suspenders — it would work correctly if the class were ever made reachable.

The real fix this PR delivers is in openai_llm.py line 502, which actually executes. The deepseek_llm.py change is included for completeness.