Commit a53a1ca
fix(provider): handle MiniMax ThinkingBlock when max_tokens reached (AstrBotDevs#5913)
* fix(provider): handle MiniMax ThinkingBlock when max_tokens reached
Fixes AstrBotDevs#5912
Problem: MiniMax API returns ThinkingBlock when stop_reason='max_tokens',
but AstrBot throws 'completion 无法解析' exception because both
completion_text and tools_call_args are empty.
Root cause: The validation logic didn't consider ThinkingBlock
(reasoning_content) as valid content.
Fix: When completion_text and tools_call_args are empty but
reasoning_content is present, treat it as valid instead of throwing
exception. This happens when the model thinks but runs out of tokens
before generating the actual response.
Impact: MiniMax models now work correctly when responses are truncated
due to max_tokens limit.
* refactor: address review feedback
1. Use getattr for safe stop_reason access (prevent AttributeError)
2. Use ValueError instead of generic Exception for better error handling
Thanks @gemini-code-assist and @sourcery-ai for the review!
* refactor: flatten nested if/else with guard clause
Address Gemini Code Assist feedback:
- Use guard clause for early return
- Flattened nested conditional for better readability
Logic unchanged, just cleaner code structure.
* fix(provider): improve logging for ThinkingBlock completions in ProviderAnthropic
---------
Co-authored-by: Soulter <905617992@qq.com>1 parent 3fd6c4c commit a53a1ca
1 file changed
Lines changed: 17 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
276 | 276 | | |
277 | 277 | | |
278 | 278 | | |
279 | | - | |
| 279 | + | |
| 280 | + | |
| 281 | + | |
280 | 282 | | |
281 | | - | |
| 283 | + | |
| 284 | + | |
| 285 | + | |
| 286 | + | |
| 287 | + | |
| 288 | + | |
| 289 | + | |
| 290 | + | |
| 291 | + | |
| 292 | + | |
| 293 | + | |
| 294 | + | |
| 295 | + | |
| 296 | + | |
282 | 297 | | |
283 | 298 | | |
284 | 299 | | |
| |||
0 commit comments