Overview - Ai

ai

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
532-tool-name-is-undefined-in-messages-after-executing-a-tool-that-needs-approval
72f3addb fix(e2e): inject X-Test-Id header for openrouter via HTTPClient hook OpenRouter's adapter previously received the testId via a query param on serverURL, but the SDK calls `new URL(path, baseURL)` per request, which drops the search component — so testId never reached aimock and every openrouter test collided on the `__default__` testId bucket. As soon as two openrouter tests sent the same userMessage, the second one's sequenceIndex didn't reset, no fixture matched, and chatStream threw. The OpenRouter SDK exposes an `httpClient` option whose `HTTPClient` supports `addHook("beforeRequest", …)`. Use that to set X-Test-Id on each request. This isolates openrouter tests the same way every other provider already is. Also reverts the earlier `test.skip(provider === 'openrouter')` on the issue #532 follow-up case — with this fix the test passes for openrouter too. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
by Tom Beckenham
Succeeded
532-tool-name-is-undefined-in-messages-after-executing-a-tool-that-needs-approval
72f3addb Merge 82ea76404605ef582b56b64a98d6f5f3d9835626 into b2d3cc131a31c54bd1e5841f958fbe333514e508
by Tom Beckenham
Succeeded
532-tool-name-is-undefined-in-messages-after-executing-a-tool-that-needs-approval
066b356c test(e2e): skip openrouter on issue #532 follow-up case Openrouter's chatStream fails on the multi-turn approval-then-followup flow for reasons unrelated to the core fix in @tanstack/ai. The unit tests in packages/typescript/ai cover the fix provider-agnostically; the other five tool-approval providers (openai, anthropic, ollama, groq, grok) still exercise it in E2E. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
by Tom Beckenham
Succeeded
532-tool-name-is-undefined-in-messages-after-executing-a-tool-that-needs-approval
066b356c test(e2e): skip openrouter on issue #532 follow-up case Openrouter's chatStream fails on the multi-turn approval-then-followup flow for reasons unrelated to the core fix in @tanstack/ai. The unit tests in packages/typescript/ai cover the fix provider-agnostically; the other five tool-approval providers (openai, anthropic, ollama, groq, grok) still exercise it in E2E. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
by Tom Beckenham
Succeeded
532-tool-name-is-undefined-in-messages-after-executing-a-tool-that-needs-approval
e3a96aa3 fix(ai): tool_use.name undefined after approving a tool then sending follow-up (#532) Synthesized TOOL_CALL_START in the post-approval continuation now sets the AG-UI spec field `toolCallName` (in addition to the deprecated `toolName` alias), so the client's StreamProcessor records a tool-call part with a defined `name` instead of `undefined`. Without the fix, the next outbound request was rejected by Anthropic with `tool_use.name: String should have at least 1 character`. Defensively, StreamProcessor now also falls back to `chunk.toolName` when `chunk.toolCallName` is missing. Additionally, after running an approved tool server-side, the agent loop replaces the `pendingExecution: true` placeholder tool message in its message history instead of appending a duplicate. This stops the Anthropic adapter's tool_result de-dup (which keeps the first match) from discarding the real result, so the model sees the actual tool output during the post-approval streaming response. Includes unit tests (chat.test.ts, stream-processor.test.ts) and an E2E case in tool-approval.spec.ts plus a matching aimock fixture. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
by Tom Beckenham
Succeeded
532-tool-name-is-undefined-in-messages-after-executing-a-tool-that-needs-approval
e3a96aa3 fix(ai): tool_use.name undefined after approving a tool then sending follow-up (#532) Synthesized TOOL_CALL_START in the post-approval continuation now sets the AG-UI spec field `toolCallName` (in addition to the deprecated `toolName` alias), so the client's StreamProcessor records a tool-call part with a defined `name` instead of `undefined`. Without the fix, the next outbound request was rejected by Anthropic with `tool_use.name: String should have at least 1 character`. Defensively, StreamProcessor now also falls back to `chunk.toolName` when `chunk.toolCallName` is missing. Additionally, after running an approved tool server-side, the agent loop replaces the `pendingExecution: true` placeholder tool message in its message history instead of appending a duplicate. This stops the Anthropic adapter's tool_result de-dup (which keeps the first match) from discarding the real result, so the model sees the actual tool output during the post-approval streaming response. Includes unit tests (chat.test.ts, stream-processor.test.ts) and an E2E case in tool-approval.spec.ts plus a matching aimock fixture. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
by Tom Beckenham