Overview - Ai

ai

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
main
44454100 fix(ai): emit TOOL_CALL_START/ARGS during continuation re-executions (#372) * test(ai): add tests for missing TOOL_CALL_START/ARGS during continuation Continuation re-executions (pending tool calls from message history) only emit TOOL_CALL_END, skipping TOOL_CALL_START and TOOL_CALL_ARGS. This causes clients to store tool calls with empty arguments, leading to infinite re-execution loops. Two tests added: - Single pending tool call emits full START → ARGS → END sequence - Batch of pending tool calls each emit full START → ARGS → END sequence * fix(ai): emit TOOL_CALL_START and TOOL_CALL_ARGS during continuation re-executions Pending tool calls resumed from message history only emit TOOL_CALL_END, causing clients to store empty arguments and triggering infinite re-execution loops. Emit the full START → ARGS → END sequence using the arguments from the original ToolCall objects. * ci: apply automated fixes * test(ai): add test for mixed pending batch with server and client tools * ci: apply automated fixes * test(e2e): add continuation re-execution tool call arguments tests Add 4 E2E tests verifying tool call arguments are preserved during continuation re-executions. Without TOOL_CALL_START/ARGS emission, clients store tool calls with empty {} arguments. Tests: - Single client tool args preserved after continuation - Sequential client tool args preserved across multiple continuations - Parallel client tool args preserved in batch continuation - Mixed server+client tool args preserved in sequence Also populate the `args` field on synthetic TOOL_CALL_ARGS chunks emitted during continuation, matching adapter-emitted chunks. --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com> Co-authored-by: Alem Tuzlak <t.zlak@hotmail.com>
by Diego Garcia
Succeeded
main
44454100 fix(ai): emit TOOL_CALL_START/ARGS during continuation re-executions (#372) * test(ai): add tests for missing TOOL_CALL_START/ARGS during continuation Continuation re-executions (pending tool calls from message history) only emit TOOL_CALL_END, skipping TOOL_CALL_START and TOOL_CALL_ARGS. This causes clients to store tool calls with empty arguments, leading to infinite re-execution loops. Two tests added: - Single pending tool call emits full START → ARGS → END sequence - Batch of pending tool calls each emit full START → ARGS → END sequence * fix(ai): emit TOOL_CALL_START and TOOL_CALL_ARGS during continuation re-executions Pending tool calls resumed from message history only emit TOOL_CALL_END, causing clients to store empty arguments and triggering infinite re-execution loops. Emit the full START → ARGS → END sequence using the arguments from the original ToolCall objects. * ci: apply automated fixes * test(ai): add test for mixed pending batch with server and client tools * ci: apply automated fixes * test(e2e): add continuation re-execution tool call arguments tests Add 4 E2E tests verifying tool call arguments are preserved during continuation re-executions. Without TOOL_CALL_START/ARGS emission, clients store tool calls with empty {} arguments. Tests: - Single client tool args preserved after continuation - Sequential client tool args preserved across multiple continuations - Parallel client tool args preserved in batch continuation - Mixed server+client tool args preserved in sequence Also populate the `args` field on synthetic TOOL_CALL_ARGS chunks emitted during continuation, matching adapter-emitted chunks. --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com> Co-authored-by: Alem Tuzlak <t.zlak@hotmail.com>
by Diego Garcia
Succeeded
main
44454100 fix(ai): emit TOOL_CALL_START/ARGS during continuation re-executions (#372) * test(ai): add tests for missing TOOL_CALL_START/ARGS during continuation Continuation re-executions (pending tool calls from message history) only emit TOOL_CALL_END, skipping TOOL_CALL_START and TOOL_CALL_ARGS. This causes clients to store tool calls with empty arguments, leading to infinite re-execution loops. Two tests added: - Single pending tool call emits full START → ARGS → END sequence - Batch of pending tool calls each emit full START → ARGS → END sequence * fix(ai): emit TOOL_CALL_START and TOOL_CALL_ARGS during continuation re-executions Pending tool calls resumed from message history only emit TOOL_CALL_END, causing clients to store empty arguments and triggering infinite re-execution loops. Emit the full START → ARGS → END sequence using the arguments from the original ToolCall objects. * ci: apply automated fixes * test(ai): add test for mixed pending batch with server and client tools * ci: apply automated fixes * test(e2e): add continuation re-execution tool call arguments tests Add 4 E2E tests verifying tool call arguments are preserved during continuation re-executions. Without TOOL_CALL_START/ARGS emission, clients store tool calls with empty {} arguments. Tests: - Single client tool args preserved after continuation - Sequential client tool args preserved across multiple continuations - Parallel client tool args preserved in batch continuation - Mixed server+client tool args preserved in sequence Also populate the `args` field on synthetic TOOL_CALL_ARGS chunks emitted during continuation, matching adapter-emitted chunks. --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com> Co-authored-by: Alem Tuzlak <t.zlak@hotmail.com>
by Diego Garcia
Succeeded
main
44454100 fix(ai): emit TOOL_CALL_START/ARGS during continuation re-executions (#372) * test(ai): add tests for missing TOOL_CALL_START/ARGS during continuation Continuation re-executions (pending tool calls from message history) only emit TOOL_CALL_END, skipping TOOL_CALL_START and TOOL_CALL_ARGS. This causes clients to store tool calls with empty arguments, leading to infinite re-execution loops. Two tests added: - Single pending tool call emits full START → ARGS → END sequence - Batch of pending tool calls each emit full START → ARGS → END sequence * fix(ai): emit TOOL_CALL_START and TOOL_CALL_ARGS during continuation re-executions Pending tool calls resumed from message history only emit TOOL_CALL_END, causing clients to store empty arguments and triggering infinite re-execution loops. Emit the full START → ARGS → END sequence using the arguments from the original ToolCall objects. * ci: apply automated fixes * test(ai): add test for mixed pending batch with server and client tools * ci: apply automated fixes * test(e2e): add continuation re-execution tool call arguments tests Add 4 E2E tests verifying tool call arguments are preserved during continuation re-executions. Without TOOL_CALL_START/ARGS emission, clients store tool calls with empty {} arguments. Tests: - Single client tool args preserved after continuation - Sequential client tool args preserved across multiple continuations - Parallel client tool args preserved in batch continuation - Mixed server+client tool args preserved in sequence Also populate the `args` field on synthetic TOOL_CALL_ARGS chunks emitted during continuation, matching adapter-emitted chunks. --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com> Co-authored-by: Alem Tuzlak <t.zlak@hotmail.com>
by Diego Garcia
Succeeded
fix/continuation-chunk-emission
c783ca51 Merge 94cc2d4ad5b126b129c55c14147d38399c4a856d into ca1ca44866030a06599133f64c699c4f2f42353c
by Diego Garcia
Succeeded
fix/continuation-chunk-emission
6e1a3525 Merge 41a47c75bdd74b34b02265968b63bfdd6bf74152 into ca1ca44866030a06599133f64c699c4f2f42353c
by Diego Garcia
Succeeded
fix/continuation-chunk-emission
98053184 Merge 654fb57efb1387f75e80fac9f311c54b67ddb153 into ca1ca44866030a06599133f64c699c4f2f42353c
by Diego Garcia
Succeeded
fix/continuation-chunk-emission
d61a04a6 Merge 8974a32a6903c4e4fdaa86c2322e5ac7236f264c into ca1ca44866030a06599133f64c699c4f2f42353c
by Diego Garcia
Succeeded
main
a25322c0 fix(ai-react): update messagesRef synchronously during render (#373) * test(ai-react): add test for messagesRef staleness on client recreation When setMessages and id change are batched into a single React render, the useEffect that updates messagesRef hasn't run yet. The new ChatClient is created with stale (empty) initialMessages, losing the conversation history. The test verifies that the adapter receives all previous messages when sending through the recreated client. * fix(ai-react): update messagesRef synchronously during render Replace useEffect ref update with synchronous render-time assignment so messagesRef is always current when useMemo creates a new ChatClient. * ci: apply automated fixes --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
by Diego Garcia
Succeeded
main
2ee0b333 fix: tool approval flow — output priority, field preservation, batch gating (#352) * test: add failing tests for tool approval flow issues Three bugs in the TextEngine's tool-call approval flow: 1. buildAssistantMessages skips concrete output when approval metadata lingers, falling through to the approval-responded path which replays the tool as pendingExecution: true (messages.ts) 2. updateToolCallPart drops existing approval and output fields when rebuilding tool-call parts during streaming (message-updaters.ts) 3. executeToolCalls runs non-approval tools in a mixed batch before the user has a chance to approve or deny the approval-needed tools (tool-calls.ts) * fix: resolve tool approval flow issues in executeToolCalls and message conversion 1. Output takes priority over approval metadata in buildAssistantMessages 2. Preserve approval and output fields when updateToolCallPart rebuilds parts 3. Batch-gate tool execution until all approval-needed tools have decisions * chore: add changeset for patch release * fix: clone approval object to avoid shared mutation, reset mock in batch test
by Diego Garcia