Commit 2b1224a
committed
fix: resolve native tool protocol race condition causing 400 errors
The issue occurred when tool results were being formatted. The code was
calling resolveToolProtocol() to determine whether to use native or XML
protocol formatting. However, if the API configuration changed between
when the tool call was made and when the result was being formatted
(e.g., user switched profiles), it would use the wrong protocol format.
This caused native protocol tool calls to be formatted with XML-style
text headers like '[tool_name] Result:', creating malformed message
structures that violated API expectations and resulted in 400 errors.
Solution:
Instead of recalculating the protocol, we now check for the presence of
an ID on the tool call itself:
- Native protocol tool calls ALWAYS have an ID (set during parsing)
- XML protocol tool calls NEVER have an ID (parsed from XML text)
This approach is race-condition-free because the ID is an immutable
property of each tool call that definitively indicates which protocol
was used to create it. It also gracefully handles provider switches -
if a provider doesn't support native tools, the tool calls simply won't
have IDs and will be formatted correctly for XML protocol.1 parent bb31b04 commit 2b1224a
1 file changed
+8
-6
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
280 | 280 | | |
281 | 281 | | |
282 | 282 | | |
283 | | - | |
284 | | - | |
285 | | - | |
| 283 | + | |
| 284 | + | |
| 285 | + | |
| 286 | + | |
286 | 287 | | |
| 288 | + | |
287 | 289 | | |
288 | 290 | | |
289 | 291 | | |
| |||
511 | 513 | | |
512 | 514 | | |
513 | 515 | | |
514 | | - | |
515 | | - | |
516 | | - | |
| 516 | + | |
| 517 | + | |
| 518 | + | |
517 | 519 | | |
518 | 520 | | |
519 | 521 | | |
| |||
0 commit comments