Overview - Ai

ai

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
main
ff267a55 fix(ai): stop emitting duplicate TOOL_CALL_END for server-executed tools (#696) * fix(ai): stop emitting duplicate TOOL_CALL_END for server-executed tools Adapters already stream START/ARGS/END for every tool call, but the post-execution phase in chat() pushed a second TOOL_CALL_END with no preceding TOOL_CALL_START. AG-UI-strict consumers (e.g. @ag-ui/client's verifyEvents) reject an orphan END and abort the stream. buildToolResultChunks now emits END only alongside the matching START it already gates on argsMap (the continuation re-execution path, which reconstructs a never-streamed call); the normal post-execution path contributes only TOOL_CALL_RESULT. The result/error state lives on the spec-compliant TOOL_CALL_RESULT, so nothing is lost. Fixes #519. * test(e2e): add #519 regression for duplicate TOOL_CALL_END Drive chat() with a server tool through an adapter that streams its own START/ARGS/END (as real adapters do) and assert the emitted lifecycle is balanced: exactly one TOOL_CALL_END per tool call, each preceded by a matching START — the invariant @ag-ui/client's verifyEvents enforces. Reproduces #519 (the orphan duplicate END) end-to-end. * test(e2e): consume open START on END in pairing invariant A second TOOL_CALL_END for the same toolCallId now fails the pairing check directly, matching how @ag-ui/client's verifyEvents closes open tool calls. Addresses CodeRabbit review feedback on #696. * fix(ai-event-client): emit devtools tool-result from TOOL_CALL_RESULT The devtools middleware sourced tool results from TOOL_CALL_END, which the adapter emits before execution (no result attached). With the #519 fix in @tanstack/ai, the post-execution END is no longer re-emitted, so results now travel on the spec-compliant TOOL_CALL_RESULT event. Handle it so server-executed tool output keeps reaching devtools.
by Valery Gutu
Succeeded
main
ff267a55 fix(ai): stop emitting duplicate TOOL_CALL_END for server-executed tools (#696) * fix(ai): stop emitting duplicate TOOL_CALL_END for server-executed tools Adapters already stream START/ARGS/END for every tool call, but the post-execution phase in chat() pushed a second TOOL_CALL_END with no preceding TOOL_CALL_START. AG-UI-strict consumers (e.g. @ag-ui/client's verifyEvents) reject an orphan END and abort the stream. buildToolResultChunks now emits END only alongside the matching START it already gates on argsMap (the continuation re-execution path, which reconstructs a never-streamed call); the normal post-execution path contributes only TOOL_CALL_RESULT. The result/error state lives on the spec-compliant TOOL_CALL_RESULT, so nothing is lost. Fixes #519. * test(e2e): add #519 regression for duplicate TOOL_CALL_END Drive chat() with a server tool through an adapter that streams its own START/ARGS/END (as real adapters do) and assert the emitted lifecycle is balanced: exactly one TOOL_CALL_END per tool call, each preceded by a matching START — the invariant @ag-ui/client's verifyEvents enforces. Reproduces #519 (the orphan duplicate END) end-to-end. * test(e2e): consume open START on END in pairing invariant A second TOOL_CALL_END for the same toolCallId now fails the pairing check directly, matching how @ag-ui/client's verifyEvents closes open tool calls. Addresses CodeRabbit review feedback on #696. * fix(ai-event-client): emit devtools tool-result from TOOL_CALL_RESULT The devtools middleware sourced tool results from TOOL_CALL_END, which the adapter emits before execution (no result attached). With the #519 fix in @tanstack/ai, the post-execution END is no longer re-emitted, so results now travel on the spec-compliant TOOL_CALL_RESULT event. Handle it so server-executed tool output keeps reaching devtools.
by Valery Gutu
Succeeded
fix/chat-duplicate-tool-call-end
c4254654 fix(ai-event-client): emit devtools tool-result from TOOL_CALL_RESULT The devtools middleware sourced tool results from TOOL_CALL_END, which the adapter emits before execution (no result attached). With the #519 fix in @tanstack/ai, the post-execution END is no longer re-emitted, so results now travel on the spec-compliant TOOL_CALL_RESULT event. Handle it so server-executed tool output keeps reaching devtools.
by Valery Gutu