Overview

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
main
7d922963 fix: preserve Responses tool call correlation IDs (#936) * fix: preserve Responses tool call correlation IDs * test: cover OpenRouter Responses tool round trips * fix: preserve streamed tool call names * test(openai-base): add a real round-trip guard for the call_id split The mock-based E2E suite cannot catch this class of bug. aimock maps an incoming `function_call.call_id` straight onto `tool_calls[].id`, so a request that uses the WRONG id consistently in both the `function_call` and its `function_call_output` still correlates and still passes. I confirmed this by running the new `openrouter-responses -- tool-calling` matrix entry against the pre-fix adapter source: it passes. Only a provider that knows the real item -> call_id mapping rejects the old shape. So the regression net has to be a unit test. `openai-base` had none for the full round trip: its request-mapping test hand-builds the assistant message including `metadata.itemId`, which assumes the very propagation that can break. Add a two-turn test that drives the real `chat()` agent loop with a server tool and asserts the second request carries both identifiers. This covers every adapter inheriting the base -- ai-openai, ai-grok, ai-bedrock, and the OpenAI-compatible adapter -- none of which override convertMessagesToInput. Verified it fails against the pre-fix source (`call_id: fc_item_1`, no `id`). Also stop labelling the output item id as `toolCallId` in the diagnostic log payloads of both Responses adapters. Now that the two identifiers differ, those fields reported the item id under the tool-call name. Each site logs `itemId`, plus `toolCallId: metadata.callId` where the metadata is in scope. --------- Co-authored-by: Alem Tuzlak <t.zlak@hotmail.com>
by Jan Kubica
Succeeded
main
7d922963 fix: preserve Responses tool call correlation IDs (#936) * fix: preserve Responses tool call correlation IDs * test: cover OpenRouter Responses tool round trips * fix: preserve streamed tool call names * test(openai-base): add a real round-trip guard for the call_id split The mock-based E2E suite cannot catch this class of bug. aimock maps an incoming `function_call.call_id` straight onto `tool_calls[].id`, so a request that uses the WRONG id consistently in both the `function_call` and its `function_call_output` still correlates and still passes. I confirmed this by running the new `openrouter-responses -- tool-calling` matrix entry against the pre-fix adapter source: it passes. Only a provider that knows the real item -> call_id mapping rejects the old shape. So the regression net has to be a unit test. `openai-base` had none for the full round trip: its request-mapping test hand-builds the assistant message including `metadata.itemId`, which assumes the very propagation that can break. Add a two-turn test that drives the real `chat()` agent loop with a server tool and asserts the second request carries both identifiers. This covers every adapter inheriting the base -- ai-openai, ai-grok, ai-bedrock, and the OpenAI-compatible adapter -- none of which override convertMessagesToInput. Verified it fails against the pre-fix source (`call_id: fc_item_1`, no `id`). Also stop labelling the output item id as `toolCallId` in the diagnostic log payloads of both Responses adapters. Now that the two identifiers differ, those fields reported the item id under the tool-call name. Each site logs `itemId`, plus `toolCallId: metadata.callId` where the metadata is in scope. --------- Co-authored-by: Alem Tuzlak <t.zlak@hotmail.com>
by Jan Kubica
Succeeded
fix/openrouter-responses-call-id
696e8107 Merge 129aef0d40b623f3957a7ce7fdd097e78a885ad9 into 40b27309a9d50ddbb66e5621a052e0eb53eb1493
by Jan Kubica
Succeeded
main
fbfd4be3 fix: preserve free-form OpenAI tool schemas (#933)
by Jan Kubica
Succeeded
main
fbfd4be3 fix: preserve free-form OpenAI tool schemas (#933)
by Jan Kubica
Succeeded
fix/openai-strict-open-object-schemas
ca959773 Merge 745adbcca649a66101a4cd5c4f8ae80f515815d1 into 5fcaf90dc82bc20b8c7a75faa3c129da04858af5
by Jan Kubica
Succeeded
feat/ai-mistral-document-input
887fb9b1 feat(ai-mistral): support document (PDF) input via document_url The Mistral text adapter already snake-cased a `document_url` part in messageToWire, but convertContentPartToMistral never produced one and threw for any `document` content part, and model-meta declared no `document` input modality. Add the document branch (mirroring the image path: hosted URLs pass through, inline bytes become a data: URL) and declare `document` input for the vision-capable models, matching how the other provider adapters expose PDF input. Verified against Mistral's API: /v1/models reports vision=true for these models, and document_url round-trips a PDF on mistral-small-latest and mistral-medium-latest (both hosted-URL and inline base64).
by Jan Kubica
Succeeded
feat/ai-mistral-document-input
887fb9b1 Merge e45dd3cf6a81e809d958bbbf1a81644447031f79 into e3de949575eac8301c0449afa3a91ef450e9580b
by Jan Kubica
Succeeded
main
4d5141c1 fix(ai-client): add missing methods to the no-op chat devtools bridge (#752) * fix(ai-client): add missing methods to the no-op chat devtools bridge The default NoOpChatDevtoolsBridge was missing mountWithTools, notifyToolsChanged, and recordStreamId, so the first ChatClient.sendMessage() threw a TypeError before appending the user message whenever no devtoolsBridgeFactory was supplied. Subsequent sends appeared to work because mountDevtools() marks itself done before calling the missing method. Rework the compile-time parity check so drift between the real and no-op bridge surfaces fails the build: the previous form assigned 'undefined as never' to the missing-keys type, which always typechecks because never is assignable to every type. Add a unit test that unmocks the suite-wide real-bridge shim so the shipping default path is exercised. * test(e2e): cover vanilla ChatClient with the default no-op devtools bridge The framework hooks always inject the real devtools bridge factory, so no existing E2E route exercised the no-op bridge that direct ChatClient consumers get by default.
by Jan Kubica
Succeeded
main
4d5141c1 fix(ai-client): add missing methods to the no-op chat devtools bridge (#752) * fix(ai-client): add missing methods to the no-op chat devtools bridge The default NoOpChatDevtoolsBridge was missing mountWithTools, notifyToolsChanged, and recordStreamId, so the first ChatClient.sendMessage() threw a TypeError before appending the user message whenever no devtoolsBridgeFactory was supplied. Subsequent sends appeared to work because mountDevtools() marks itself done before calling the missing method. Rework the compile-time parity check so drift between the real and no-op bridge surfaces fails the build: the previous form assigned 'undefined as never' to the missing-keys type, which always typechecks because never is assignable to every type. Add a unit test that unmocks the suite-wide real-bridge shim so the shipping default path is exercised. * test(e2e): cover vanilla ChatClient with the default no-op devtools bridge The framework hooks always inject the real devtools bridge factory, so no existing E2E route exercised the no-op bridge that direct ChatClient consumers get by default.
by Jan Kubica
Succeeded
fix/noop-chat-devtools-bridge-parity
20303e49 Merge 0f95b999334bc3b9ab70acb8a6aa27bab4c3db20 into 984ac3c8a59e4aef6d3e80b89b2d7986af818850
by Jan Kubica