Commit fca3ed5
fix: correct tool_choice dict format handling (fixes @ihower feedback)
Critical fix based on testing feedback from @ihower:
The previous fix assumed Responses Converter format (flat dict), but
LiteLLM uses ChatCompletions Converter which returns nested format.
Problem identified by @ihower:
- response_tool_choice was always "auto" even with specific tool names
- Root cause: Looking for wrong dict structure
Converter formats:
- ChatCompletions: {"type": "function", "function": {"name": "tool_name"}} ✅ (LiteLLM uses this)
- Responses: {"type": "function", "name": "tool_name"} ❌ (NOT used here)
Fix:
- Changed from tool_choice.get("name") to tool_choice.get("function").get("name")
- Added proper type checking for func_data dict
- Maintained all defensive checks (non-empty string, valid type, etc.)
Testing:
- Created comprehensive unit tests
- Created end-to-end flow tests
- All tests pass with nested dict format
- Verified: ModelSettings(tool_choice="my_tool") → ToolChoiceFunction(name="my_tool")
Generated with Lucas Wang<[email protected]>
Co-Authored-By: Claude <[email protected]>1 parent 8abed69 commit fca3ed5
1 file changed
+11
-7
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
377 | 377 | | |
378 | 378 | | |
379 | 379 | | |
380 | | - | |
381 | | - | |
382 | | - | |
| 380 | + | |
| 381 | + | |
| 382 | + | |
383 | 383 | | |
384 | 384 | | |
385 | | - | |
386 | | - | |
387 | | - | |
| 385 | + | |
| 386 | + | |
388 | 387 | | |
389 | | - | |
| 388 | + | |
| 389 | + | |
| 390 | + | |
| 391 | + | |
| 392 | + | |
| 393 | + | |
390 | 394 | | |
391 | 395 | | |
392 | 396 | | |
| |||
0 commit comments